Re: Odd merge behaviour involving reverts

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