diff options
Diffstat (limited to 'Documentation/howto/revert-a-faulty-merge.txt')
| -rw-r--r-- | Documentation/howto/revert-a-faulty-merge.txt | 18 |
1 files changed, 11 insertions, 7 deletions
diff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt index 6fd711996a..462255ed5d 100644 --- a/Documentation/howto/revert-a-faulty-merge.txt +++ b/Documentation/howto/revert-a-faulty-merge.txt @@ -7,6 +7,10 @@ Abstract: Sometimes a branch that was already merged to the mainline after the offending branch is fixed. Message-ID: <7vocz8a6zk.fsf@gitster.siamese.dyndns.org> References: <alpine.LFD.2.00.0812181949450.14014@localhost.localdomain> +Content-type: text/asciidoc + +How to revert a faulty merge +============================ Alan <alan@clueserver.org> said: @@ -33,7 +37,7 @@ where A and B are on the side development that was not so good, M is the merge that brings these premature changes into the mainline, x are changes unrelated to what the side branch did and already made on the mainline, and W is the "revert of the merge M" (doesn't W look M upside down?). -IOW, "diff W^..W" is similar to "diff -R M^..M". +IOW, `"diff W^..W"` is similar to `"diff -R M^..M"`. Such a "revert" of a merge can be made with: @@ -50,7 +54,7 @@ where C and D are to fix what was broken in A and B, and you may already have some other changes on the mainline after W. If you merge the updated side branch (with D at its tip), none of the -changes made in A nor B will be in the result, because they were reverted +changes made in A or B will be in the result, because they were reverted by W. That is what Alan saw. Linus explains the situation: @@ -86,7 +90,7 @@ with: $ git revert W This history would (ignoring possible conflicts between what W and W..Y -changed) be equivalent to not having W nor Y at all in the history: +changed) be equivalent to not having W or Y at all in the history: ---o---o---o---M---x---x-------x---- / @@ -117,9 +121,9 @@ If you reverted the revert in such a case as in the previous example: ---A---B A'--B'--C' where Y is the revert of W, A' and B' are rerolled A and B, and there may -also be a further fix-up C' on the side branch. "diff Y^..Y" is similar -to "diff -R W^..W" (which in turn means it is similar to "diff M^..M"), -and "diff A'^..C'" by definition would be similar but different from that, +also be a further fix-up C' on the side branch. `"diff Y^..Y"` is similar +to `"diff -R W^..W"` (which in turn means it is similar to `"diff M^..M"`), +and `"diff A'^..C'"` by definition would be similar but different from that, because it is a rerolled series of the earlier change. There will be a lot of overlapping changes that result in conflicts. So do not do "revert of revert" blindly without thinking.. @@ -160,7 +164,7 @@ 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 +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. |