Re: Odd merge behaviour involving reverts

Nanako Shiraishi <nanako3@lavabit.com> writes:

The history immediately after the "revert of the merge" would look like this:

 ---o---o---o---M---x---x---W---x
               /     
       ---A---B

where A and B are on the side development that was not so good, M is the merge that brings those premature changes into the mainline, x are unrelated changes 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".

I think you misunderstood what "merging an updated version of the branch" meant by Alan's description to mean that the side branch developers discarded their faulty A and B, and redone the changes, which would have resulted in something like:

 ---o---o---o---M---x---x---W---x---x
                                 \
                                  A'--B'--C'

If that were the situation, suggestion by Linus to revert the revert and then merge would result in something like this:

 ---o---o---o---M---x---x---W---x---x---Y---*
                                 \         /
                                  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, because it is a rerolled series of the earlier change. There would be a lot of overlap as you feared. In such a case, not having Y (revert of the revert) would result in a much more trivial merge:

 ---o---o---o---M---x---x---W---x---x-------*
                                 \         /
                                  A'--B'--C'

because problematic large commits M and W are already outside of the scope of this final merge.

But I think what Alan's developers did is different. They did this instead:

 ---o---o---o---M---x---x---W---x
               /
       ---A---B-------------------C---D

where C and D are to fix what was broken in A and B. In such a situation, what Linus suggests makes perfect sense. You first revert the revert, which would result in this:

 ---o---o---o---M---x---x---W---x---Y
               /
       ---A---B-------------------C---D

where Y is the revert of W, which would (ignoring possible conflicts between what W and W..Y changed) be equivalent to not having W nor Y at all in the history:

 ---o---o---o---M---x---x-------x----
               /
       ---A---B-------------------C---D

and merging the side branch again will not have conflict arising from an earlier revert and revert of revert.

 ---o---o---o---M---x---x-------x-------*
               /                       /
       ---A---B-------------------C---D

Of course the changes made in C and D still can conflict with what was done by any of the x, but that is just a normal merge conflict.

To recap, these are two very different scenarios, and wants two very different resolution strategies:

 - If the faulty side branch whose effects were discarded by an earlier
   revert of a merge was rebuilt from scratch (i.e. rebasing and fixing,
   as you seem to have interpreted), then re-merging the result without
   doing anything else fancy would be the right thing to do.

 - If the faulty side branch was fixed by adding corrections on top, then
   doing a revert of the previous revert would be the right thing to do.

I hope this clears up confusion and fear.