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

[Junio C Hamano <gitster@pobox.com>]

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

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

The topic is depended on Phillip's "git replay" tweak to drop
commits that are originally not-empty and become empty in the
replayed history, blocking its advance, which is doubly unfortunate.

Thanks.