From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 20 Feb 2026 20:23:55 GMT
Subject: Re: [PATCH v3 2/2] replay: add --revert mode to reverse commit changes
Message-ID: <xmqqy0knw4dg.fsf@gitster.g>
In-Reply-To: <87tsvbe2sm.fsf@iotcl.com>

Toon Claes <toon@iotcl.com> 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 <newbase> | --advance <branch>) [--ref-action[=<mode>]] <revision-range>
>> +(EXPERIMENTAL!) 'git replay' ([--contained] --onto <newbase> | --advance <branch> | --revert <branch>) [--ref-action[=<mode>]] <revision-range>...
>
> 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=<branch> <revision-range>
>     git replay pick --base=<branch> <revision-range>
>     git replay replay --base=<branch> <revision-range>

Given the earlier discussion on confusions (mostly by those like me
who weren't closely watching the topics around this command) on what
options among --onto, --advance, etc. were incompatible, etc., that
certainly does sound like a good way to make these distinctive modes
more clearly stand out.

Thanks.