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 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..
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 to a) store their local work in another branch (than the one you are going to overwrite) b) reset -hard 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. -- 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.
