Re: Regarding howto/revert-a-faulty-merge.txt - another way to revert a merge
Noam Yorav-Raphael <noamraph@gmail.com> writes:
Show 13 quoted lines
> This is fine, but it means that you must remember to revert the revert
> before the next merge, which may be hard to remember. I thought of
> another solution: In the source branch, add a commit reverting all the
> changes since the previous merge, then merge again from that brange to
> the master branch, and then revert the revert. In a diagram:
>
> ----o---o---o---M---o---o------------W-------
> / / /
> ------o---A---B---C-------!C!B!A---o----ABC--
>
> (`!C!B!A` means a commit that reverts C, B and A, returning to `o`.
> `ABC` means a commit that applies A, B and C, thus returning to the
> tree after C.)
These, we definitely do not want them [*].
> Now the W commit really reverts the M commit, and you can forget about it.
>
> Would you be interested in a patch adding this to
> howto/revert-a-faulty-merge.txt?
What you have above is a moral equivalent to the "On the other hand" senario. In the picture in the existing document, the new incarnation of A'-B'-C' chain folks from the commit after W, but it does not have to (it could even be a fork from the original A^). IOW, there is no need for the A'-B'-C' chain to be strict descendant of the original C like the above picture.
What happens in practice (and I do this myself sometimes when I have to revert out a topic out of 'next') is
* Revert W of a merge M is made.
* At the very same time, the original A--B--C chain is discarded,
and the topic is rebased on some appropriate base (e.g. the
parent of original A in your picture, for example, or the commit
after W in the "On the other hand" part of the exicting document,
exact base chosen does not matter all that much) to create an
updated A'--B'--C' commits. While this chain is being polished
(without getting merged into the integration branch to become a
descendant of W), you may rebase them again and again until they
are polished enough. And then you merge the result, which will
lead to "If you reverted the revert in such a case" topology in
the existing document.
So if you want to avoid "we can forget that we have reverted" problem, not reverting the revert, but rebuilding the entire chain, is a better approach that gives you cleanest history to work with, and that is what we already offer as an alternative of "reverting a revert", not "squashed revert and squashed reapply on the side branch".
So, I dunno if we want to add yet another one.
[Footnote]
* We do not want the squashed CBA!!! revert or ABC reapply, both of
which are large balls of wax that interferes with bisectability.
Noam Yorav-Raphael