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

["SZEDER Gábor" <szeder.dev@gmail.com>]

On Tue, Jan 13, 2026 at 10:54:39AM +0100, Patrick Steinhardt wrote:
> Implement a new "reword" subcommand for git-history(1). This subcommand
> is similar to the user performing an interactive rebase with a single
> commit changed to use the "reword" instruction.
> 
> The "reword" subcommand is built on top of the replay subsystem
> instead of the sequencer. This leads to some major differences compared
> to git-rebase(1):
> 
>   - We do not check out the commit that is to be reworded and instead
>     perform the operation in-memory. This has the obvious benefit of
>     being significantly faster compared to git-rebase(1), but even more
>     importantly it allows the user to rewrite history even if there are
>     local changes in the working tree or in the index.

In an earlier round I pointed out some of the differences between the
'reword' instruction of 'git rebase' and 'git history rebase',
including some drawbacks of the latter.  It's disheartening to see
that you only picked those differences that are in favor of your 'git
history' command, but neglected its drawbacks.

Please strive for less biased and more objective commit messages.

>   - We do not execute any hooks, even though we leave some room for
>     changing this in the future.
> 
>   - By default, all local branches that contain the commit will be
>     rewritten. This especially helps with workflows that use stacked
>     branches.

Please don't just state that all local branches containing the
modified commit are rewritten, but justify why it behaves that way.

Git's porcelain commands operate on the current branch, unless the
user specifies a different branch or an option like '--all' or
'--branches'.  The default chosen here is inconsistent with the rest
of Git.

This is a bad default for any future subcommands implementing common
history rewriting operations that can cause conflicts.

Users must remember to specify a non-default '--ref-action' if they
don't want this behavior.  If they forget to do so and don't notice
it, the old commits will be gc-ed away.  Therefore, I consider this
to be a dangerous default that can lead to data loss.

I firmly believe that operating on all local branches must always be
the result of an explicit user action.