Re: [PATCH RFC v2 2/2] builtin/history: abort reword on same message

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 10, 2026, 16:02 UTC
Message-ID: <xmqq33yuxu1x.fsf@gitster.g>
In-Reply-To: <aikMLBCC9Rc7q9S7@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 16 quoted lines

> On Tue, Jun 09, 2026 at 12:17:51PM -0700, Junio C Hamano wrote:
>> Pablo Sabater <pabloosabaterr@gmail.com> 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.