Re: [PATCH v6 05/11] builtin/history: implement "reword" subcommand

From: Patrick Steinhardt <ps@pks.im>
Date: Dec 2, 2025, 18:50 UTC
Message-ID: <aS81CgKzerDkHlS1@pks.im>
In-Reply-To: <aSVpXPtrqa0cBsEm@szeder.dev>

On Tue, Nov 25, 2025 at 09:31:24AM +0100, SZEDER Gábor wrote:

Show 9 quoted lines

> On Mon, Oct 27, 2025 at 12:33:53PM +0100, Patrick Steinhardt wrote:
> > Implement a new "reword" subcommand for git-history(1). This subcommand
> > is essentially the same as if a user performed an interactive rebase
> > with a single commit changed to use the "reword" verb.
> 
> s/verb/instruction/
> 
> The behavior is not nearly "essentially the same", because 'git
> history reword' doesn't check out the reworded commit.

True, this is a leftover from before. I'll reword this.

Show 17 quoted lines

> This is a substantial drawback when writing a commit message for
> anything non-trivial.  I, for one, often like to take a look at the
> "big picture", i.e. the actual file content in the reworded commit, in
> case the diff included in the commit message template doesn't show
> enough context, or even run Git commands built from that particular
> revision to be able to accurately describe its behavior.
> 
> OTOH, I understand that this might be deemed desirable in some cases,
> like when rewording a commit to correct a simple typo, because source
> file mtimes stay intact, or when the worktree contains modified files.
> 
> It would be great if this new command could somehow support both use
> cases.
> 
> In any case, this significant behavior difference (and its drawbacks)
> is not mentioned let alone justified in the commit message, it is not
> documented anywhere, and it is not really tested, either.

I guess it's a mixed bag. The big benefit of not having to check out the commit is that it's as fast as it gets. All we need to do is to rewrite commit history, and we don't need to check anything out. This has the obvious benefit of being fast, but also the less-obvious benefit of being able to deal with changes that exist in the working tree, only.

Show 24 quoted lines

> > Signed-off-by: Patrick Steinhardt <ps@pks.im>
> > ---
> >  Documentation/git-history.adoc |   7 +-
> >  builtin/history.c              | 331 ++++++++++++++++++++++++++++++++++++++++-
> >  t/meson.build                  |   1 +
> >  t/t3450-history.sh             |   6 +-
> >  t/t3451-history-reword.sh      | 237 +++++++++++++++++++++++++++++
> >  5 files changed, 573 insertions(+), 9 deletions(-)
> > 
> > diff --git a/Documentation/git-history.adoc b/Documentation/git-history.adoc
> > index 6bdfeb50e8b..bd903875120 100644
> > --- a/Documentation/git-history.adoc
> > +++ b/Documentation/git-history.adoc
> > @@ -8,7 +8,7 @@ git-history - EXPERIMENTAL: Rewrite history of the current branch
> >  SYNOPSIS
> >  --------
> >  [synopsis]
> > -git history [<options>]
> > +git history reword <commit>
> 
> I'm not sure I like this interface, because I have to know in advance
> how to specify the revision I want to reword, and I usually don't know
> that.  Choosing the commit from the rebase instruction sheet seems to
> be much simpler, more intuitive and less error prone.

Fair. For me I would very much prefer this new interface, but it's certainly a matter of taste.

Patrick