From: Christian Couder Date: Mon, 23 Feb 2026 09:13:15 GMT Subject: Re: [PATCH v3 2/2] replay: add --revert mode to reverse commit changes Message-ID: In-Reply-To: <87tsvbe2sm.fsf@iotcl.com> On Fri, Feb 20, 2026 at 6:35 PM Toon Claes wrote: > > Siddharth Asthana writes: > > 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: > > git replay revert --base= > git replay pick --base= > git replay replay --base= (I think you mean `git replay rebase` in the above line, no?) I agree that we should consider this. But I think we should do it separately in another series, after this one about --revert is merged. We might even consider waiting until we have more experience using `git replay --revert` to make a more informed decision. We shouldn't wait for too long either though... Also if we nearly always need a base, then why not: git replay rebase git replay pick git replay revert ? Or what was the reason for introducing --base=?