From: Siddharth Asthana Date: Fri, 06 Mar 2026 05:05:21 GMT Subject: Re: [PATCH v3 2/2] replay: add --revert mode to reverse commit changes Message-ID: <31384cd8-6739-40dd-a963-ce1597921969@gmail.com> In-Reply-To: <87tsvbe2sm.fsf@iotcl.com> On 20/02/26 23:05, Toon Claes wrote: > Siddharth Asthana writes: > >> Add a `--revert ` mode to git replay that undoes the changes >> introduced by the specified commits. Like --onto and --advance, --revert >> is a standalone mode: it takes a branch argument and updates that branch >> with the newly created revert commits. >> >> At GitLab, we need this in Gitaly for reverting commits directly on bare >> repositories without requiring a working tree checkout. >> >> The approach is the same as sequencer.c's do_pick_commit() -- cherry-pick >> and revert are just the same three-way merge with swapped arguments: >> >> - Cherry-pick: merge(ancestor=parent, ours=current, theirs=commit) >> - Revert: merge(ancestor=commit, ours=current, theirs=parent) >> >> We swap the base and pickme trees passed to merge_incore_nonrecursive() >> to reverse the diff direction. >> >> Revert commit messages follow the usual git revert conventions: prefixed >> with "Revert" (or "Reapply" when reverting a revert), and including >> "This reverts commit .". The author is set to the current user >> rather than preserving the original author, matching git revert behavior. >> >> Helped-by: Christian Couder >> Helped-by: Patrick Steinhardt >> Helped-by: Elijah Newren >> Helped-by: Phillip Wood >> Helped-by: Johannes Schindelin >> Helped-by: Junio C Hamano >> Signed-off-by: Siddharth Asthana >> --- >> Documentation/git-replay.adoc | 37 +++++++- >> builtin/replay.c | 25 ++++-- >> replay.c | 162 ++++++++++++++++++++++++---------- >> replay.h | 11 ++- >> t/t3650-replay-basics.sh | 107 ++++++++++++++++++++-- >> 5 files changed, 277 insertions(+), 65 deletions(-) >> >> diff --git a/Documentation/git-replay.adoc b/Documentation/git-replay.adoc >> index 8d696ce3ab..ffdf790278 100644 >> --- a/Documentation/git-replay.adoc >> +++ b/Documentation/git-replay.adoc >> @@ -9,7 +9,7 @@ git-replay - EXPERIMENTAL: Replay commits on a new base, works with bare repos t >> SYNOPSIS >> -------- >> [verse] >> -(EXPERIMENTAL!) 'git replay' ([--contained] --onto | --advance ) [--ref-action[=]] >> +(EXPERIMENTAL!) 'git replay' ([--contained] --onto | --advance | --revert ) [--ref-action[=]] ... > > The modes `--onto`, `--advance` and `--revert` seem to be extremely > different from each other. So I'm starting to wonder whether it won't > make more sense to instead create subcommands instead of options for > these. Maybe something like: Agree the interface could be cleaner as subcommands. I think Christian's suggestion to do this separate series after --revert lands make sense -- we would get real-world usage feedback first, and it avoids scope creep here. > > git replay revert --base=

> git replay pick --base=

> git replay replay --base=

> >