Re: [PATCH v11 8/8] builtin/history: implement "reword" subcommand

From: Patrick Steinhardt <ps@pks.im>
Date: Feb 5, 2026, 08:19 UTC
Message-ID: <aYRSjhnS8VQPSHa0@pks.im>
In-Reply-To: <xmqqsebivgop.fsf@gitster.g>

On Mon, Feb 02, 2026 at 04:01:10PM -0800, Junio C Hamano wrote:

Show 29 quoted lines

> Elijah Newren <newren@gmail.com> writes:
> 
> > On Fri, Jan 16, 2026 at 8:28 AM SZEDER Gábor <szeder.dev@gmail.com> wrote:
> >>
> > ...
> > Personally, I'm having difficulty understanding your second stated
> > advantage of picking the commit from the rebase instruction sheet.
> > That instruction sheet is obtained by rebasing on top of something,
> > and it seems as easy to me to see the commits since that point in a
> > git log command and pick your desired commit from log output as it is
> > to invoke an interactive rebase on top of that base commit to get the
> > rebase instruction sheet and then pick out your desired commit from
> > there.  Same number of operations and work either way, so I don't see
> > how either is more or less work than the other.
> >
> > You did make a good point that one of the differences is that you
> > don't have the commit checked out.  That's a useful distinction to be
> > aware of.  To me, that seems to be somewhat implied already both by
> > "in-memory" and "even if there are local changes in the working tree
> > or index", though it wouldn't hurt to explicitly call it out.
> >
> > It feels like each of your complaints with the new proposed commands
> > (given commit not checked out, rebase instruction sheet vs listing
> > commit, and HEAD-only) can be boiled down to the fact that they don't
> > behave like `git rebase`.  Is that accurate?  If you like rebase, is
> > there a reason you are worried you can't just keep using it?  I don't
> > see why others should be required to implement another exact copy of
> > rebase, though.  Further, if we only wanted minor modifications, we
> > could have just done those to git rebase.

git-history(1) is definitely quite different compared to git-rebase(1), and that's by design. Not everyone will like it, and many folks will probably continue to just use git-rebase(1) themselves. But as you say, it does address some use cases that git-rebase(1) doesn't handle itself, and it tries to provide an opinionated interface to make common tasks easier to handle for folks who aren't advanced users.

I of course wouldn't mind highlighting more of the differences in the docs and/or the commit message, of course. It's tough sometimes to find the right level of details.

Show 13 quoted lines

> >> I firmly believe that operating on all local branches must always be
> >> the result of an explicit user action.
> >
> > Over at https://lore.kernel.org/git/aUVaEPGoOkATQGl3@szeder.dev/ , you
> > alternatively suggested the idea of an "escape hatch".  I think that
> > may be a good idea.  What if we had a "history.scope" config variable,
> > with values like "descendant-branches", "current-branch", and
> > "error-if-multiple-branches", corresponding to each of the requested
> > defaults we've seen in response to this series?  I can't imagine using
> > anything other than descendant-branches, and the preponderance of
> > those who have commented on the default so far seem to be in
> > agreement, but it would allow you and Matthias and others like you two
> > to pick an alternative.  Thoughts?

I would certainly be happy to add such an escape hatch to the command so that it only rewrites the current branch. We already have the infrastructure for that in place anyway, so it's trivial to add a configuration key that changes the default.

> The discussion stalled after this exchange.  What is the next move?
> I think the it is SZEDER's turn to respond?

I dunno. From my point of view I still believe this is ready to be merged. Sure, there will be follow-up topics:

  - The above configuration to make it work on a single branch, only.

  - First-class conflicts. This is something that I also discussed with
    Elijah already, and we will coordinate on this topic going forward.

  - Additional subcommands, of course.

But I don't think that missing support for first-class conflicts needs to hold back this topic. The proposed command cannot result in conflicts anyway, and there's more commands that won't. Furthermore, the command is marked as experimental, so the initial versions are expected to be somewhat limited in their functionality so that we can get feedback and iterate on the design if we see that it needs some tweaking.

Thanks!

Patrick