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

From: Toon Claes <toon@iotcl.com>
Date: Feb 23, 2026, 11:23 UTC
Message-ID: <87pl5vem9g.fsf@iotcl.com>
In-Reply-To: <CAP8UFD1CAYZwK4x4-AZWjx3cubzu5WcndR8WJzhcegET+i22nA@mail.gmail.com>

Christian Couder <christian.couder@gmail.com> writes:

Show 12 quoted lines

> On Fri, Feb 20, 2026 at 6:35 PM Toon Claes <toon@iotcl.com> wrote:
>>
>> 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>
>
> (I think you mean `git replay rebase` in the above line, no?)

I'm fine either way, but I agree saying "replay" twice looks weird.

Show 5 quoted lines

> 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...

I can agree with that.

Show 9 quoted lines

> Also if we nearly always need a base, then why not:
>
>   git replay rebase <base> <revision-range>
>   git replay pick <base> <revision-range>
>   git replay revert <base> <revision-range>
>
> ?
>
> Or what was the reason for introducing --base=<branch>?

Well, the modes 'revert' and 'pick' work different from 'replay'. The latter looks in <revision-range> to determine which refs need updating. This can lead to multiple refs that will be updated (with option --contained). The first two only operate on one ref and ignore whatever refs are in <revision-range>. (I think, correct me if I'm wrong)

That's why I suggest to take it one step further:

     git replay revert --ref=<branch> <revision-range>
     git replay pick --ref=<branch> <revision-range>
     git replay rebase --onto=<branch> <revision-range>

That's why the first two use --ref instead of --onto.

As a benefit, this also enables me to address another issue I have: git-replay(1) cannot be used on bare commit IDs. This issue was also raised by Yee Cheng Chin[1].

With options `--onto` and `--ref` we can fix this. Because you can use them together:

    git replay replay --ref=ref/heads/branch --onto=112233 aabbcc..ddeeff
    git replay pick --ref=ref/heads/branch --onto=112233 aabbcc..ddeeff
    git replay rebase --ref=ref/heads/branch --onto=112233 aabbcc..ddeeff

The value of --onto doesn't need to be a ref, but --ref needs. For the 'rebase' subcommand option --ref is optional, for the other two --onto is optional. And when one of both is omitted, one defaults to the other.

What do you think?

[1]: https://lore.kernel.org/git/CAHTeOx-SMLh_idKhGczPKzZNOKy04uYXmUhL8Z79yRuNpmE4eA@mail.gmail.com/

-- 
Cheers,
Toon