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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 9, 2026, 19:30 UTC
Message-ID: <xmqq5x3r1ph0.fsf@gitster.g>
In-Reply-To: <aihH8ye-r4QuXlRD@denethor>

Justin Tobler <jltobler@gmail.com> writes:

Show 13 quoted lines

> I can see a situation where a user performs:
>
>   git history reword abcd1234
>
> with the intention to modify a commit message, but then for some reason
> changes their mind and doesn't want history to change. Maybe the wrong
> commit was referenced, or they decide the current message is actually
> fine. From my understanding, there isn't a great way to abort rewording
> a commit during editing and thus the user would have to reset history
> afterwards if they care enough to go back to the previous point.
>
> So I do see some value in a mechanism to abort rewriting a commit
> message.

I think we are saying the same thing in different ways. I want to see that command "succeed" either case (normally we create a new commit object because we record an updated committer timestamp, but if there is no need to create a new commit object only to record an updated committer timestamp, we may choose not to and leave the history intact) and I do not want it to *abort*.

The mechanism to do so may be exactly the same, i.e., accept an updated log message, then try to "hash-object" (without -w) the commit object with everything, except for the updated commit log message, taken from the original commit, plus the updated log message. And if the resulting hash is the same as the original, do not do anything further and return happily. Aborting sounds more like complaining loudly "baa, you asked me to reword but you gave me the same message? is anything wrong with you?" with non-zero exit status, which I think the user does not deserve in such a case.