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

Phillip Wood [off-list ref] writes:

quoted

Hi Pablo

On 09/06/2026 11:42, Pablo Sabater wrote:

quoted

  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