Subject: Re: [PATCH v4 0/2] replay: add --revert mode to reverse commit changes

From: Toon Claes <[email-masked]>
Date: Mon, 16 Mar 2026 20:53:52 +0100

Siddharth Asthana <[email-masked]> writes:

> Hi,
>
> git replay currently supports cherry-picking (--advance) and rebasing
> (--onto), but not reverting. We need this at GitLab for Gitaly to
> reverse commits directly on bare repositories without a checkout.
>
> The approach is the same as sequencer.c -- cherry-pick and revert are
> just the same three-way merge with swapped arguments. We swap the base
> and pickme trees passed to merge_incore_nonrecursive() to reverse the
> diff direction.
>
> Patch 1 extracts the full revert message formatting logic into a new
> sequencer_format_revert_message() function, following Phillip's
> suggestion to move everything into one shared function rather than
> just the header. refer_to_commit() is updated to take a struct
> repository and a bool instead of replay_opts so it works outside the
> sequencer.
>
> Patch 2 adds --revert <branch> as a standalone mode. Reverts are
> processed newest-first (matching git revert) to reduce conflicts by
> peeling off changes from the top.
>
> The series is based on top of d181b9354c (The 13th batch, 2026-03-07).
>
> CI: https://gitlab.com/gitlab-org/git/-/pipelines/2329880894
> The msvc-meson / Chocolatey failures are pre-existing infrastructure
> issues unrelated to this series.
>
> Changes in v4:
> - Replaced sequencer_format_revert_header() with a more complete
>   sequencer_format_revert_message() that handles everything: subject
>   prefix, commit reference via refer_to_commit(), and merge-parent
>   references -- per Phillip
> - Updated refer_to_commit() signature to take (struct repository *r,
>   bool use_commit_reference) instead of (struct replay_opts *opts)
> - Reverts are now newest-first (revs.reverse = 0 for --revert),
>   chaining on last_commit rather than the parent mapping
> - Changed doc example to cross-branch scenario and restored the
>   merge-tree NOTE
> - Updated error message format to "'--revert' cannot be used with
>   multiple revision ranges..." (and same for --advance)
> - Empty revert commits are now dropped, consistent with cherry-pick
> - Link to v3: https://public-inbox.org/git/[email-masked]/
> - Link to v2: https://public-inbox.org/git/[email-masked]/
> - Link to v1: https://public-inbox.org/git/[email-masked]/
>
> Thanks,
> Siddharth

I've added various nitpicks here and there. Overall nothing really
blocking for a reroll I think, but maybe the combination of them all is.

-- 
Cheers,
Toon