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

From: SZEDER Gábor <szeder.dev@gmail.com>
Date: Jan 16, 2026, 16:28 UTC
Message-ID: <aWpnFqTmWB9XIWUW@szeder.dev>
In-Reply-To: <20260113-b4-pks-history-builtin-v11-8-e74ebfa2652d@pks.im>

On Tue, Jan 13, 2026 at 10:54:39AM +0100, Patrick Steinhardt wrote:

Show 13 quoted lines

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

Show 6 quoted lines

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