From: Junio C Hamano Date: Wed, 10 Jun 2026 16:02:34 GMT Subject: Re: [PATCH RFC v2 2/2] builtin/history: abort reword on same message Message-ID: In-Reply-To: Patrick Steinhardt writes: > On Tue, Jun 09, 2026 at 12:17:51PM -0700, Junio C Hamano wrote: >> Pablo Sabater writes: >> >> >> > I wonder if we should check that the committer identity is unchanged as >> >> > well in case anyone is using this to fix commits after committing with >> >> > the wrong identity. >> > >> > I think that if you reword a commit committed by someone else but end >> > up with no changes I want it to be kept as it was. >> >> That depends on the reason why the feature to "reword" the commit is >> being used, and the use case Phillip is talking about is a bit >> different. > > So the answer is "it depends". Maybe we should do handle this the same > as git-commit(1) does with its "--reset-author" flag? Interesting. I was mostly focusing on the committer identity, but the same argument of courese also applies to the author identity. Having said that, if the user who used to commit others' patches under a wrong identity (i.e., the only thing incorrect about these commits is the committer identity, and author identity of them are not to be updated), "--reset-author" would not be usable, as they want to keep the authorship information recorded. I think (1) in the shorter term, always create a new commit by default even if the only difference were the committer timestamp. But add a mechanism to allow users to tell the tool to skip the update in such a case. (2) at a big version bump, flip the default, making the "always create a new commit" an optional feature. would be the way to go, and the way to trigger that mechanism needs to be separate from "--reset-author". Thanks.