Nanako Shiraishi <nanako3@xxxxxxxxxxx> writes:
> If I understand Alan's case correctly, I think he does not want to
> "undo" the revert but wants to merge an updated version of the branch,
> as if no mistaken merge nor its revert happened in the past.
>
> 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?
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.
--
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
