Re: Regarding howto/revert-a-faulty-merge.txt - another way to revert a merge

[Junio C Hamano <gitster@pobox.com>]

Noam Yorav-Raphael <noamraph@gmail.com> writes:

> 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.