Usage of pull rebasing and merges

[Oswald Buddenhagen]

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 <<