On 02/03/13 12:08, Thomas Ferris Nicolaisen wrote:
On Saturday, March 2, 2013 12:23:07 AM UTC+1, Philip Oakley wrote:
From: "Philip Oakley" <philip...@iee.org <javascript:>>
Sent: Friday, March 01, 2013 10:36 PM
>I have two PCs, one running Windows Msysgit & Git for Windows, which
>I'm familiar with, and the other a laptop with Ubuntu (still not
>familiar). I have a repo hosted on GitHub.
>
> I rebased a branch on my windows PC and pushed it to Github with a
> forced update.
>
> I've now fetched the branch to my laptop (Ubuntu) and want to update
> that branch to the remote branch tip. The [old] branch is checked
out
> on the laptop, but the remote/branch is +/- 3 commits different
> because of the rebase I did on the Windows PC.So how to
sychronise to
> the remote?
>
> I'm sort of wanting the ability to do a 'git pull --ff-only
--force '
> or perhaps 'git pull --ff-force' (if they existed) in this
"typical"
> real user situation. Such that there is no merge in my branch's
> 'tree'. The 'recovering from rebase' section of rebase(1) doesn't
> appear to cover this typical(?) case.
No sooner than I send in the email that little bit of extra googling
finds
http://stackoverflow.com/q/4084868/717355
<http://stackoverflow.com/q/4084868/717355> which appears to cover
my situation
i.e.
# on local branch
git reset --hard remote/branch
Maybe I should suggest a doc update for the synchronisation case. I
just
didn't think of looking at the 'git reset' man page, but browsed
checkout,
fetch, pull, merge, et and found nothing that appeared to fit.
>
> In my current situation I could simply go behind the scenes to
rewrite
> the contents of the refs/heads/<branch> to match the
> refs/remote/<branch> sha1 pointer, and then do a 'git reset
--hard' to
> update the work tree.
>
> My question is, is there a short simple, or single, command sequence
> that uses the poreclain commands to do this typical update? (and
is it
> documented somewhere)
>
> Philip
Yeah, this is basically the main reason why rebasing is "evil", or at
least highly confusing. Imagine if that had happened with a whole team
of developers and not just a single machine..
In this case it was just me, and the problem is synchronising between my
different working machines, so when I do a rebase, I do need such a
mechanism.
This use case appears to be part of the natural use of rebase - I'm
preparing a patch series and as part of its development I need to
re-order patches, add in comments to commit messages etc as I review how
well it reads after the fact, but I don't really want hundreds of
personal temporary branches, so I use rebase.
However I also need to synchronise this branch between machines with
different OS's (one has the Msysgit DAG, while the other Junio's DAG, so
they have a common root but different working branches).
Plus, for researching the issue, its tricky deciding on what search
words are needed for googling for this particular problem.
I'm sure the resolving of the 'team' rebase could be made easier (for
those who don't have local work) if these simple commands (in
retrospect) were more obvious in the documentation.
One of the 'evil' problems of rebase is that it doesn't leave a
transferable marker of where it's old head was so the recipient would
know if they had extra commits relative to the pre-rebase branch (I
don't think it can in a distributed system anyway)
These are one of those things you pick up along the way: If you ever
have to do a forced push, make sure you warn your collaborators
(I don't have any in this case ;-)
to
a) store their local work in another branch (than the one you are going
to overwrite)
b) reset -hard
I think it's this invocation that needs documenting for this use case.
after you have force pushed to correct their local repository
After using Git in a team for a couple of years, I think we've had to go
through this only a couple of times. In nearly all cases, it's not
worth it.
The confusion there would be public vs private branches (never publish
to a public branch that _will_ be used by team mates). But I would still
expect that individual developers would need to fixup and rework their
private branches before publishing to a public branch. And if they have
two machines they need to be able to synchronise their private branch
between the machines, which is my use case as I get to grips with
Linux/Ubuntu.
Thanks for the comments and discussion.
Philip Oakley
--
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
