Re: [PATCH 0/1] replay: add --revert option to reverse commit changes

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 26, 2025, 21:04 UTC
Message-ID: <xmqqcy54mro6.fsf@gitster.g>
In-Reply-To: <27fef9e1-bf26-48af-b3df-35948937c891@gmail.com>

Siddharth Asthana <siddharthasthana31@gmail.com> writes:

Show 8 quoted lines

> 1. For quick undoing an entire MR, the `merge-tree` approach you 
> suggest is indeed more efficient and avoids unnecessary intermediate 
> conflicts.
>
> 2. For commit-by-commit reverts, we need individual revert commits with 
> proper attribution (which commit is being reverted) for auditability and 
> history clarity. This is particularly useful when only specific commits 
> from a merged branch need to be reverted.

These are both good workflows with appropriate uses. To make the tool useful for #2, it needs to be able to allow "I have merged a topic with 7 commits, but the first commit and the fourth commit are faulty and I need to revert them", i.e., not just a range (like "rebase" and "cherry-pick" workflows take), but a set of commits that are potentially disconnected. The current command line arguments "git replay" supports, or "git revert A..B" for that matter, are not exactly a good fit for such a use case, although the user can of course run two single-commit revert operations in a row.