On Tue, Feb 08, 2011 at 09:20:55PM +1300, Ben Cooksley wrote: > Do not run "git pull --rebase" after performing the merge, under any > circumstances. > ding ding ding - bingo!
On Wed, Feb 02, 2011 at 10:27:02AM +0100, Oswald Buddenhagen wrote: > and remember that following receipes does *not* work if you don't > actually understand what you are doing - there may always be some > circumstances that make it a receipe for disaster. and from experience i > can tell that some people are astonishingly stubborn with ignoring signs > of disaster ... guess what i meant by that? here's the first mail i wrote to the internal trolltech mailing list regarding that topic: > if you are merging an upstream branch (say, 4.5 => 4.6) and afterwards > the push goes wrong (because 4.6 has moved on already), then don't even > *think* about using the usually strongly recommended git pull --rebase > to get to an up-to-date state - it would rebase the merged 4.5 commits. > there are basically two approaches: > > - just throw away the merge with git reset --hard HEAD~1 and redo it > after git pull-ing. preferably, you should have git rerere enabled, > so you won't have to repeat resolving any possible conflicts. > > - if you are a lazy sod, you can exceptionally use a regular git pull > (at the usual cost of the merge looking particularly bizarre in gitk, > etc.) > > also, push any "proper" merges asap - otherwise you might forget about > them and get into the same situation as above. > > it's better to push out any local changes before starting an upstream > merge, as otherwise you are mixing two workflows with contradicting > recommendations wrt. rebasing. > > in case you do screw up, you should usually notice that - rebase says > which commits it is processing, so you should see that something bogus > is going on. then you can use git reflog and git reset --hard to the > last good state - and simply start over. the great thing about git is, > that every messup is undoable as long as the good state was committed at > some point. > > of course, all this goes without saying for those who enhanced their > personal horizon by going through the effort of actually understanding > what rebases, etc. do. this is not an exclusive club - *you* could play > with the cool guys, too. ;) guess what happened a few weeks later? yup, right: > On Wed, Nov 18, 2009 at 03:33:33AM +0100, some troll wrote: > > Since the 4.6.0 branch was created, several very large chunks of > > history have been duplicated with new SHA1's and then pushed back > > into the 4.6 branch as a result of misguided use of git pull > > --rebase. > > > let me put it that way: AAARRRGH!!! > > somebody here suggested that i should comment one that issue, as that's > obviously what happened before here in berlin. the thing is: i already > did, and there was some additional good input from olivier. > > people, really, how on earth do you manage to plain ignore the fact that > git just rebased tens or hundreds of commits? i mean, it is several > screenfuls of unexpected output! how can this not ring *all* alarm bells > in *anyone*!?!?!? > > oh, well. i give up. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
