Re: [PATCH RFC 1/2] builtin/history: abort reword on unchanged message
> Le 8 juin 2026 à 08:23, Junio C Hamano <gitster@pobox.com> a écrit :
>
Show 12 quoted lines
> 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.
FWIW, in this situation I abort my editor (:cquit in Vim) so that the amend gets an error-valued exit code from the subprocess and aborts itself.
Perhaps there could/should be a better side-channel for communicating that, though? I do not know how easy it is to tell other editors to « quit with errors ».
Show 14 quoted lines
> [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.
Ben Knoble <ben.knoble@gmail.com>