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

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

[Noam Yorav-Raphael]

Hi,

I was looking for a way to revert a merge, and found the document at
howto/revert-a-faulty-merge.txt. It basically suggests that if you
reverted a merge and want to re-merge, you should first revert the
revert.

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

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?

Thanks,
Noam

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

[Junio C Hamano]

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.

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

[Noam Yorav-Raphael]

On Tue, Jun 25, 2024 at 12:03 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> These, we definitely do not want them [*].
>  * We do not want the squashed CBA!!! revert or ABC reapply, both of
>    which are large balls of wax that interferes with bisectability.

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

If you don't mind rebasing the branch, what you're suggesting is fine.
However, if it's a long-running branch, with multiple people working
on it, rebasing is not an option. In that case, I think that my
suggestion makes a lot of sense. A good idea would be to add the
"large balls of wax" commits to a `.git-blame-ignore-revs` (or
whatever you choose to call it) file.

Cheers,
Noam