On Thu, 18 Dec 2008, Linus Torvalds wrote: > 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! Another option is to do the big revert on the master branch, and on the side branch merge the parent of the revert (normally), and then merge the revert but take the side branch tree. That last merge puts the revert in the branch's history, but rejects its effects. Now merging the branch again will find the revert to be the common ancestor, and see the full change of the side branch as the contribution of that side. Also, blame will come down the side branch, ignore the merge (on the side branch, the merge contributed no content changes), and go into the original side branch commits. You can also think of it as the side branch saying, "I noticed that you reverted my changes, but I'm keeping them anyway". When the final merge comes, git will see that the revert isn't new information to the side branch, and nullify its effect. (Of course, the side branch needs to merge the parent of the revert so that it isn't rejecting the other changes made on the main branch before the revert) -Daniel *This .sig left intentionally blank* -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
