From: Pablo Sabater Date: Tue, 09 Jun 2026 10:14:05 GMT Subject: Re: [PATCH RFC 1/2] builtin/history: abort reword on unchanged message Message-ID: In-Reply-To: El lun, 8 jun 2026 a las 14:16, Junio C Hamano () escribió: > [snip] > > `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. True, after reading it, history being more costly or the in memory are not good args. I do agree that these commands that do reword should check if the reword ends up being the same message, given that history is a new command we can have it from the start so users do not really expect other behavior. About the --force sounds good to me. I could seek to implement it in this series if it's ok. The footnote 3 is indeed a good example haha, but yeah, why rewrite the history unnecessarily. Thanks, Pablo