Re: Odd merge behaviour involving reverts

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

On Fri, 19 Dec 2008, Nanako Shiraishi wrote:
> 
> If you revert the revert on the branch before merging, doesn't it mean 
> that you will be merging what the older version of the branch did (that 
> is in the revert of the revert as a single huge patch) and what the 
> updated version of the branch wants to do?  Wouldn't that lead to a mess 
> with huge conflicts?

Actually, the reverse is likely true. If the branch you are merging is 
actually doing something branch-specific - ie it's a "topic branch", then 
it's likely that the new stuff that is on that branch depends on the 
previous stuff on the branch.

And thats' the thing that got reverted - so with just a revert, it's quite 
likely that you'll get conflicts. But if you revert the revert, now the 
new stuff you're merging actually makes more sense, and is less likely to 
conflict.

Another way of looking at it is that a merge is something that can be done 
both ways: think of the _other_ branch merging yours. The original revert 
ends up being a big change-patch that undoes everything that other branch 
did, so now if that other branch were to merge the main branch, you'd be 
merging a lot of changes. But reverting the revert will undo all those 
changes, so again, it's more likely that the merge will succeed.

So revertign a revert is usually going to make subsequent merges easier 
rather than the reverse. 

The _big_ problem with reverting a whole merge is that it effectively 
becomes one commit that does a big change. That's how _normal_ merges tend 
to look like in CVS or SVN (ie the "merge" is really just another commit 
that brings in a lot of changes), and it's a total and utter f*cking 
disaster!

But don't get me wrong - it's not something you can't work with. I'm just 
trying to say that it's absolutely not a "good model". It's workable, but 
it has all these painful issues.

For example, think about what reverting a merge (and then reverting the 
revert) does to bisectability. Ignore the fact that the revert of a revert 
is undoing it - just think of it as a "single commit that does a lot". 
Because that is what it does.

When you have a problem you are chasing down, and you hit a "revert this 
merge", what you're hitting is essentially a single commit that contains 
all the changes (but obviously in reverse) of all the commits that got 
merged. So it's debugging hell, because now you don't have lots of small 
changes that you can try to pinpoint which _part_ of it changes.

But does it all work? Sure it does. You can revert a merge, and from a 
purely technical angle, git did it very naturally and had no real 
troubles. It just considered it a change from "state before merge" to 
"state after merge", and that was it. Nothing complicated, nothing odd, 
nothing really dangerous. Git will do it without even thinking about it.

So from a technical angle, there's nothing wrong with reverting a merge, 
but from a workflow angle it's something that you generally should try to 
avoid. 

If at all possible, for example, if you find a problem that got merged 
into the main tree, rather than revert the merge, try _really_ hard to 
bisect the problem down into the branch you merged, and just fix it, or 
try to revert the individual commit that caused it.

Yes, it's more complex, and no, it's not always going to work (sometimes 
the answer is: "oops, I really shouldn't have merged it, because it wasn't 
ready yet, and I really need to undo _all_ of the merge"). So then you 
really should revert the merge, but when you want to re-do the merge, you 
now need to do it by reverting the revert.

		Linus