Patrick Steinhardt [off-list ref] writes:

On Tue, Jun 09, 2026 at 12:17:51PM -0700, Junio C Hamano wrote:

quoted

Pablo Sabater [off-list ref] writes:

quoted

quoted

quoted

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.