Re: Odd merge behaviour involving reverts

On Thu, 2008-12-18 at 15:58 -0800, Linus Torvalds wrote:

On Thu, 18 Dec 2008, Alan wrote:

quoted

What am i doing wrong here?

Reverting a merge is your problem.

You can do it, but you seem to have done it without understanding what it 
causes.

Obviously.

A revert of a merge becomes a regular commit that just undoes everything 
that the merge did in your branch. When you then do the next merge, you'll 
do that merge with that in mind, so now git will essentially consider the 
previous merge to be the base line, but your revert undid everything that 
that one brought in, so the new merge will really only contain the new 
stuff from the branch you are merging. 

So I will have to look for previous reverts (or "pre-verts") before
merging again.

So if a merge causes problems, you generally should either undo it 
_entirely_ (ie do a 'git reset --hard ORIG_HEAD'), not revert it. 

Of course, if you had already made the merged state public, or done 
development on top of it, you can't really do that. In which case a revert 
works, but if you want it back, you should revert the revert, not merge 
the branch again - because what you merged last time you threw away, and 
won't be applied again.

On this code base, there were 30+ branches merged before the powers that
be decided to have me pull that one.  It was in the middle of the pile.

I think I know how to fix it.  I am just concerned about having it occur
again if someone else makes the same mistake I did.

Thanks.