Re: Odd merge behaviour involving reverts

From: Alan <alan@clueserver.org>
Date: Dec 19, 2008, 00:11 UTC
Message-ID: <1229645511.5770.29.camel@rotwang.fnordora.org>
In-Reply-To: <alpine.LFD.2.00.0812181534310.14014@localhost.localdomain>

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

Show 9 quoted lines

> 
> On Thu, 18 Dec 2008, Alan wrote:
> > 
> > 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.

Show 6 quoted lines

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

Show 8 quoted lines

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