Re: [PATCH RFC 1/2] builtin/history: abort reword on unchanged message

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 8, 2026, 12:16 UTC
Message-ID: <xmqqmrx5z0po.fsf@gitster.g>
In-Reply-To: <20260607-ps-history-reword-v1-1-ba43a3cbb81b@gmail.com>

Pablo Sabater <pabloosabaterr@gmail.com> writes:

Show 13 quoted lines

> When using `git history reword` if the new message is the same as the
> original it continues anyway creating a new commit with the same
> message and updates its descendants, modifying the history after this
> 'reworded' commit even though there was no actual change.
>
> `git commit --amend` and `git rebase -i` + reword share this behavior,
> however `git history reword` is different:
> 1. Works in-memory without touching the index or the worktree [1], so
>    there are no side effects like staged files that could justify
>    rewriting the history when the commit message is the same.
> 2. `git history` by default updates all the branches [2] that contain the
>    original commit making it more costly than `git rebase -i` that only
>    updates the current branch.

I think the reasoning is flawed.

Both "git commit --amend" and "git rebase -i", even with no changes to the tree, parents, or the message, update the committer timestamp (and perhaps the committer identity running the command may be different from the original). Updating this info is one of the important effects of the command.

And "history" being more capable than "rebase" is a wrong excuse to make the system behave inconsistently between commands that have similar features [*1*]. In a situation where letting 'history' update all the relevant branches, if a command behaves differently from the way the user likes (and if the way 'rebase -i' works is the one the user likes), you'd end up forcing the user to use 'rebase -i' when 'history' would have been more appropriate.

Having said that, I personally think that the current behaviour of `commit --amend` and `history reword` are both _wrong_ [*2*].

You may start `git commit --amend`, and after staring at the existing commit log message for some time in your editor, it is quite natural for you to decide that leaving the commit as-is is the right thing [*3*] in your situation. It may have been a better design for the system to notice this situation and leave the commit as-is, with an override option `--force` to allow users to forcibly update the committer ident and timestamp in the commit header. I am not a `history reword` user (yet), but from the motivation you described for this patch, I sense that the story is the same there.

`git rebase -i A`, when A is truly an ancestor at the bottom of a linear history leading to HEAD, behaves slightly better. It gives you a todo list with a bunch of `pick` insns, and when you do not edit earliest 'pick's the todo list, these earliest commits are left as-is. It may still share the same issue that a 'reword' that you ended up not rewording (or 'edit' that you ended up not touching its tree or log message) does still recreate a new commit object, though.

`git rebase -i` may have an excuse that because it, unlike "git commit --amend", operates on multiple commits by design. A single "--force" option given to the command would not have worked as an escape hatch to allow the user to tell the command "in this reword of this particular commit, I ended up doing nothing, but I still want an updated committer log timestamp". Perhaps giving the "--force" (or --force-rewrite") option at "rebase --continue" time may work, but in any case, unless we plan to transition to these "better" default behaviour at a big version boundary, speculating what a "better" behaviour would have been may be fun but not very productive.

[Footnote]

 *1* Besides, doesn't "--update-refs" in "rebase -i" allow you to
     adjust the branches?

 *2* But it is an established behaviour people _rely_ on, so even
     though it may have been better if these commands behaved
     differently, it probably is a bit too late to change it now.

 *3* This includes the case where the original author is especially
     difficult to work with and would complain any change to their
     commits, even if the only change you made for them is a
     typofix.  Fixing a small typo/grammo may not be worth your time
     and unpleasant exchanges with them after touching their commit.