Re: [PATCH 1/1] replay: add --revert option to reverse commit changes

From: Elijah Newren <newren@gmail.com>
Date: Nov 26, 2025, 23:06 UTC
Message-ID: <CABPp-BHcCX8LDccRoarsqNO=YVr7a8gp67oc87b7taAmjch4dQ@mail.gmail.com>
In-Reply-To: <xmqq3460mr3c.fsf@gitster.g>

On Wed, Nov 26, 2025 at 1:17 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 22 quoted lines

>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Elijah Newren <newren@gmail.com> writes:
> >
> >>> I'm struggling to understand when I'd want to do this. Why would I want
> >>> to update 'feature' to point to the reverted version of its last tree
> >>> commits rebased onto 'main'?
> >>> ...
> >> I was going to say the same thing, but from a different angle.
> >>
> >> The sequencer in git is used for three different types of operations:
> >> rebasing, cherry-picking, and reverting a range (with a sequence of
> >> reverts rather than one big revert).  In replay, these correspond to
> >> --onto, --advance, and the new thing you are trying to add.  As such,
> >> it should be its own new mode.
> >
> > This is a great comment that clarifies what the problem is with this.
>
> Stepping back a bit, is it just me who thinks that the "--onto"
> option is a misnamed "--rebase", and the "--advance" option is a
> misnamed "--cherry-pick"?

Is the goal to make connections between existing commands for folks already very familiar with git, at the expense of comprehensibility for new users and command lines that look somewhat illogical?

For either a rebase or a cherry-pick operation you have: (A) a range of commits to be transplanted, (B) a base on which to build from, and (C) the choice of which ref(s) should be updated to point to the transplanted commits. cherry-pick assumed HEAD for both (B) and (C). rebase formed an implicit range instead of letting the user specify (in a way which has always made it difficult to teach to new users, IMO, but I digress), which involves HEAD and also used HEAD for (C). git replay removes all assumptions about HEAD, which means there is much more freedom for (A), (B), and (C), but I think it also makes it more important to try to make command lines at least a bit more self-describing for users to learn.

== Example command lines today ==

  git replay --onto main feature~3..feature

This command replays the commits in the range feature~3..feature onto main, and updates feature to point at the result.

  git replay --advance main feature~3..feature

This command replays the commits in the range feature~3..feature onto main, and advances main to point at the result.

(Both replay the same commit range on the same base, they differ only in which refs are updated at the end.)

== Example command lines from your proposal ==

   git replay --rebase main feature~3..feature

This command to me would suggest that main is being rebased, but it isn't -- it rebases feature~3..feature onto main while updating feature to point at the result. I find the "--rebase main" part of this command line confusing.

   git replay --cherry-pick main feature~3..feature

This command to me would suggest that main is being cherry-picked, but it isn't -- it cherry-picks feature~3..feature onto main while updating main to point at the result. Again, I find the "--cherry-pick main" part of this command line confusing.