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

From: Justin Tobler <jltobler@gmail.com>
Date: Jun 9, 2026, 18:02 UTC
Message-ID: <aihH8ye-r4QuXlRD@denethor>
In-Reply-To: <xmqq4ijbsn2m.fsf@gitster.g>

On 26/06/09 09:20AM, Junio C Hamano wrote:

Show 31 quoted lines

> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
> > Hi Pablo
> >
> > On 09/06/2026 11:42, Pablo Sabater wrote:
> >>   static int commit_tree_ext(struct repository *repo,
> >> @@ -135,6 +136,13 @@ static int commit_tree_ext(struct repository *repo,
> >>   					  original_body, action, &commit_message);
> >>   		if (ret < 0)
> >>   			goto out;
> >> +
> >> +		if (flags & COMMIT_TREE_ABORT_ON_SAME_MESSAGE &&
> >> +		    !strcmp(original_body, commit_message.buf)) {
> >> +			fprintf(stderr, _("Message unchanged, aborting reword.\n"));
> >> +			ret = 1;
> >> +			goto out;
> >> +		}
> >
> > 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.
> >
> > Aborting when the message and committer identity are unchanged seems 
> > like a good idea.
> 
> I am not sure why it would be a good idea.  The user wanted to make
> the commit have this message, and the commit ended up having the
> same message as the user gave.  That message may have been identical
> to what the commit originally had, or it may be different.  Why is
> the former an abort-worthy event?  A simple note, I may understand,
> but aborting with an error message?

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. An unchanged commit message does seem like a reasonable signal to essentially abort the reword. I'm not sure committer identity should be taken into consideration though since it would inhibit a users ability to abort the reword if they ever touch a commit that they themselves are not the previous committer.

I don't think there is a need to have an error message though. Even in the case where the user leaves the commit message unchanged and history is left untouched, git-history(1) would be following exactly what the user instructed it to do. I don't really see why the user should care whether history was actually modified or not in such a scenario.

-Justin