Re: Odd merge behaviour involving reverts

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, 18 Dec 2008, Alan wrote:
> 
> So what is the recommended way to undo mistaken merges caught after the
> fact that will not fubar later merges?

Oh, I suspect reverting is the right thing, it's just that then you need 
to remember to revert the revert if you intend to merge that branch again 
later.

So reverting a merge isn't _wrong_ per se. It's just that you need to be 
aware of the consequences, and if it becomes a common situation, you have 
a problem in your usage patterns.

Btw, even with non-merge commits, "revert" can have interesting effects 
exactly because it doesn't change history. For example, let's say that you 
had a history like this, with two branches:

	--> a --> b --> c --> d
	      |
	      +-> e --> !a

where the second branch reverts 'a', but the first one does not. What 
happens when you merge the two branches? Is the revert sticky? In this 
case, yes, a merge will cause the revert to stick. But what happens if you 
had

	--> a --> b --> c --> d
	      |
	      +-> e --> f --> !e

and 'b' and 'e' were the same patch (just applied in two different 
branches), and '!e' reverts that patch in the second branch. What happens 
to 'b' when you merge? Would you expect for 'b' to go away, since the 
revert undid the same data in the second branch?

In that second case, the revert of 'e' will basically make git act as if 
'e' didn't happen at all in the second branch, and so when you merge them, 
'b' _will_ exist in the end result, so now the revert didn't "take".

All of this is very self-consistent (it's a very direct result of how 
merges work and how revert works), but I'm just bringing these things up 
as examples of how 'revert' is not a totally trivial matter. You'll always 
find cases where you might have wished that it had acted differently when 
you merge things.



			Linus