> When using `git history reword` if the new message is the same as the
> original it continues anyway creating a new commit with the same
> message and updates its descendants, modifying the history after this
> 'reworded' commit even though there was no actual change.
> 
> `git commit --amend` and `git rebase -i` + reword share this behavior,
> however `git history reword` is different:
> 1. Works in-memory without touching the index or the worktree [1], so
>    there are no side effects like staged files that could justify
>    rewriting the history when the commit message is the same.
> 2. `git history` by default updates all the branches [2] that contain the
>    original commit making it more costly than `git rebase -i` that only
>    updates the current branch.
> 
> Add a check if the original commit message is the same as the new one
> and abort if so.
> 
> [1]: https://lore.kernel.org/git/20260113-b4-pks-history-builtin-v11-8-e74ebfa2652d@pks.im/
> [2]: https://git-scm.com/docs/git-history#_description

> Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com>
> ---
>  builtin/history.c         | 10 ++++++++++
>  t/t3451-history-reword.sh | 20 ++++++++++++++++++++
>  2 files changed, 30 insertions(+)
> 
> diff --git a/builtin/history.c b/builtin/history.c
> index 0fc06fb204..51a22a9a1c 100644
> --- a/builtin/history.c
> +++ b/builtin/history.c
> @@ -135,6 +135,13 @@ static int commit_tree_ext(struct repository *repo,
>  					  original_body, action, &commit_message);
>  		if (ret < 0)
>  			goto out;
> +
> +		if (!strcmp(original_body, commit_message.buf)) {
> +			fprintf(stderr, _("Message unchanged,"
> +					  " aborting reword.\n"));
> +			ret = 1;
> +			goto out;
> +		}
>  	} else {
>  		strbuf_addstr(&commit_message, original_body);
>  	}

> Unlike `git commit --amend` and `git rebase -i`, `git history reword`
> doesn't print anything, this makes it feel empty for a porcelain command
> and hard to tell if the command did anything without using other
> commands like `git log <commit>` to check if the reword was done.
> 
> Print a message on successful rewords so the user has feedback about it.

> diff --git a/builtin/history.c b/builtin/history.c
> index 51a22a9a1c..0f1ba3b531 100644
> --- a/builtin/history.c
> +++ b/builtin/history.c
> @@ -739,6 +739,10 @@ static int cmd_history_reword(int argc,
>  		goto out;
>  	}
>  
> +	fprintf(stderr, _("Successfully reworded commit %s to %s\n"),
> +		repo_find_unique_abbrev(repo, &original->object.oid, DEFAULT_ABBREV),
> +		repo_find_unique_abbrev(repo, &rewritten->object.oid, DEFAULT_ABBREV));
> +

>
> On Sun, Jun 07, 2026 at 10:07:21PM +0200, Pablo Sabater wrote:
> > Unlike `git commit --amend` and `git rebase -i`, `git history reword`
> > doesn't print anything, this makes it feel empty for a porcelain command
> > and hard to tell if the command did anything without using other
> > commands like `git log <commit>` to check if the reword was done.
> >
> > Print a message on successful rewords so the user has feedback about it.
>
> I dunno about this one. My take here is that a command should be silent
> unless it has something to say, for example when it couldn't honor the
> user's request [1].

>
> > diff --git a/builtin/history.c b/builtin/history.c
> > index 51a22a9a1c..0f1ba3b531 100644
> > --- a/builtin/history.c
> > +++ b/builtin/history.c
> > @@ -739,6 +739,10 @@ static int cmd_history_reword(int argc,
> >               goto out;
> >       }
> >
> > +     fprintf(stderr, _("Successfully reworded commit %s to %s\n"),
> > +             repo_find_unique_abbrev(repo, &original->object.oid, DEFAULT_ABBREV),
> > +             repo_find_unique_abbrev(repo, &rewritten->object.oid, DEFAULT_ABBREV));
> > +
>
> Seeing the implementation also raises a couple of questions:
>
>   - Why do we mention the rewritten commit, only? Shouldn't we also
>     print the changed HEAD?

>
> It might make sense to maybe introduce a verbose mode where we do print
> such information. But if so, we should have good answers to the above
> questions and implement this in a way that makes sense for the other
> subcommands, too, so that we can apply the same principle to all of
> them.

>
> Thanks!
>
> Patrick
>
> [1]: https://www.linfo.org/rule_of_silence.html

>
> On Sun, Jun 07, 2026 at 10:07:20PM +0200, Pablo Sabater wrote:
> > When using `git history reword` if the new message is the same as the
> > original it continues anyway creating a new commit with the same
> > message and updates its descendants, modifying the history after this
> > 'reworded' commit even though there was no actual change.
> >
> > `git commit --amend` and `git rebase -i` + reword share this behavior,
> > however `git history reword` is different:
> > 1. Works in-memory without touching the index or the worktree [1], so
> >    there are no side effects like staged files that could justify
> >    rewriting the history when the commit message is the same.
> > 2. `git history` by default updates all the branches [2] that contain the
> >    original commit making it more costly than `git rebase -i` that only
> >    updates the current branch.
> >
> > Add a check if the original commit message is the same as the new one
> > and abort if so.
> >
> > [1]: https://lore.kernel.org/git/20260113-b4-pks-history-builtin-v11-8-e74ebfa2652d@pks.im/
> > [2]: https://git-scm.com/docs/git-history#_description
>
> Nit: I feel like both of the links don't really add much value.

>
> > Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com>
> > ---
> >  builtin/history.c         | 10 ++++++++++
> >  t/t3451-history-reword.sh | 20 ++++++++++++++++++++
> >  2 files changed, 30 insertions(+)
> >
> > diff --git a/builtin/history.c b/builtin/history.c
> > index 0fc06fb204..51a22a9a1c 100644
> > --- a/builtin/history.c
> > +++ b/builtin/history.c
> > @@ -135,6 +135,13 @@ static int commit_tree_ext(struct repository *repo,
> >                                         original_body, action, &commit_message);
> >               if (ret < 0)
> >                       goto out;
> > +
> > +             if (!strcmp(original_body, commit_message.buf)) {
> > +                     fprintf(stderr, _("Message unchanged,"
> > +                                       " aborting reword.\n"));
> > +                     ret = 1;
> > +                     goto out;
> > +             }
> >       } else {
> >               strbuf_addstr(&commit_message, original_body);
> >       }
>
> We also execute this logic via "git history fixup --reedit-message", and
> here it wouldn't make sense to abort the commit in case the message is
> unchanged.

> Unlike `git commit --amend` and `git rebase -i`, `git history reword`
> doesn't print anything, this makes it feel empty for a porcelain command
> and hard to tell if the command did anything without using other
> commands like `git log <commit>` to check if the reword was done.
>
> Print a message on successful rewords so the user has feedback about it.
>
> Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com>
> ---
>  builtin/history.c         |  4 ++++
>  t/t3451-history-reword.sh | 14 ++++++++++++++
>  2 files changed, 18 insertions(+)
>
> diff --git a/builtin/history.c b/builtin/history.c
> index 51a22a9a1c..0f1ba3b531 100644
> --- a/builtin/history.c
> +++ b/builtin/history.c
> @@ -739,6 +739,10 @@ static int cmd_history_reword(int argc,
>  		goto out;
>  	}
>  
> +	fprintf(stderr, _("Successfully reworded commit %s to %s\n"),
> +		repo_find_unique_abbrev(repo, &original->object.oid, DEFAULT_ABBREV),
> +		repo_find_unique_abbrev(repo, &rewritten->object.oid, DEFAULT_ABBREV));
> +
>  	ret = 0;
>  
>  out:

> diff --git a/t/t3451-history-reword.sh b/t/t3451-history-reword.sh
> index 54ea8a7207..4b22d761e3 100755
> --- a/t/t3451-history-reword.sh
> +++ b/t/t3451-history-reword.sh
> @@ -416,4 +416,18 @@ test_expect_success 'aborts if the commit message is the same' '
>  	)
>  '
>  
> +test_expect_success 'prints feedback on successful reword' '
> +	test_when_finished "rm -rf repo" &&
> +	git init repo &&
> +	(
> +		cd repo &&
> +		test_commit first &&
> +
> +		reword_with_message HEAD 2>err <<-EOF &&
> +		first reworded
> +		EOF
> +		test_grep "Successfully reworded" err
> +	)
> +'
> +
>  test_done

> When using `git history reword` if the new message is the same as the
> original it continues anyway creating a new commit with the same
> message and updates its descendants, modifying the history after this
> 'reworded' commit even though there was no actual change.
>
> `git commit --amend` and `git rebase -i` + reword share this behavior,
> however `git history reword` is different:
> 1. Works in-memory without touching the index or the worktree [1], so
>    there are no side effects like staged files that could justify
>    rewriting the history when the commit message is the same.
> 2. `git history` by default updates all the branches [2] that contain the
>    original commit making it more costly than `git rebase -i` that only
>    updates the current branch.

>
> Pablo Sabater <pabloosabaterr@gmail.com> writes:
>
> > Unlike `git commit --amend` and `git rebase -i`, `git history reword`
> > doesn't print anything, this makes it feel empty for a porcelain command
> > and hard to tell if the command did anything without using other
> > commands like `git log <commit>` to check if the reword was done.
> >
> > Print a message on successful rewords so the user has feedback about it.
> >
> > Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com>
> > ---
> >  builtin/history.c         |  4 ++++
> >  t/t3451-history-reword.sh | 14 ++++++++++++++
> >  2 files changed, 18 insertions(+)
> >
> > diff --git a/builtin/history.c b/builtin/history.c
> > index 51a22a9a1c..0f1ba3b531 100644
> > --- a/builtin/history.c
> > +++ b/builtin/history.c
> > @@ -739,6 +739,10 @@ static int cmd_history_reword(int argc,
> >               goto out;
> >       }
> >
> > +     fprintf(stderr, _("Successfully reworded commit %s to %s\n"),
> > +             repo_find_unique_abbrev(repo, &original->object.oid, DEFAULT_ABBREV),
> > +             repo_find_unique_abbrev(repo, &rewritten->object.oid, DEFAULT_ABBREV));
> > +
> >       ret = 0;
> >
> >  out:
>
> Do other commands in "git history" (split is in 'master', drop and
> fixup are cooking) behave with similar verbosity?  Consistency within
> the same "history" umbrella matters more than being similar with
> other commands that can be used for similar purposes.

>
> > diff --git a/t/t3451-history-reword.sh b/t/t3451-history-reword.sh
> > index 54ea8a7207..4b22d761e3 100755
> > --- a/t/t3451-history-reword.sh
> > +++ b/t/t3451-history-reword.sh
> > @@ -416,4 +416,18 @@ test_expect_success 'aborts if the commit message is the same' '
> >       )
> >  '
> >
> > +test_expect_success 'prints feedback on successful reword' '
> > +     test_when_finished "rm -rf repo" &&
> > +     git init repo &&
> > +     (
> > +             cd repo &&
> > +             test_commit first &&
> > +
> > +             reword_with_message HEAD 2>err <<-EOF &&
> > +             first reworded
> > +             EOF
> > +             test_grep "Successfully reworded" err
> > +     )
> > +'
> > +
> >  test_done

> Le 7 juin 2026 à 16:08, Pablo Sabater <pabloosabaterr@gmail.com> a écrit :
> 
> When using `git history reword` if the new message is the same as the
> original it continues anyway creating a new commit with the same
> message and updates its descendants, modifying the history after this
> 'reworded' commit even though there was no actual change.
> 
> `git commit --amend` and `git rebase -i` + reword share this behavior,
> however `git history reword` is different:
> 1. Works in-memory without touching the index or the worktree [1], so
>   there are no side effects like staged files that could justify
>   rewriting the history when the commit message is the same.
> 2. `git history` by default updates all the branches [2] that contain the
>   original commit making it more costly than `git rebase -i` that only
>   updates the current branch.
> 
> Add a check if the original commit message is the same as the new one
> and abort if so.
> 
> [1]: https://lore.kernel.org/git/20260113-b4-pks-history-builtin-v11-8-e74ebfa2652d@pks.im/
> [2]: https://git-scm.com/docs/git-history#_description
> 
> Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com>
> ---
> builtin/history.c         | 10 ++++++++++
> t/t3451-history-reword.sh | 20 ++++++++++++++++++++
> 2 files changed, 30 insertions(+)
> 
> diff --git a/builtin/history.c b/builtin/history.c
> index 0fc06fb204..51a22a9a1c 100644
> --- a/builtin/history.c
> +++ b/builtin/history.c
> @@ -135,6 +135,13 @@ static int commit_tree_ext(struct repository *repo,
>                      original_body, action, &commit_message);
>        if (ret < 0)
>            goto out;
> +
> +        if (!strcmp(original_body, commit_message.buf)) {
> +            fprintf(stderr, _("Message unchanged,"
> +                      " aborting reword.\n"));
> +            ret = 1;
> +            goto out;
> +        }
>    } else {
>        strbuf_addstr(&commit_message, original_body);
>    }
> @@ -718,6 +725,9 @@ static int cmd_history_reword(int argc,
>    if (ret < 0) {
>        ret = error(_("failed writing reworded commit"));
>        goto out;
> +    } else if (ret == 1) {
> +        ret = 0;
> +        goto out;
>    }
> 
>    strbuf_addf(&reflog_msg, "reword: updating %s", argv[0]);
> diff --git a/t/t3451-history-reword.sh b/t/t3451-history-reword.sh
> index de7b357685..54ea8a7207 100755
> --- a/t/t3451-history-reword.sh
> +++ b/t/t3451-history-reword.sh
> @@ -396,4 +396,24 @@ test_expect_success 'retains changes in the worktree and index' '
>    )
> '
> 
> +test_expect_success 'aborts if the commit message is the same' '
> +    test_when_finished "rm -rf repo" &&
> +    git init repo &&
> +    (
> +        cd repo &&
> +        test_commit first &&
> +        test_commit second &&
> +
> +        git rev-parse HEAD >oid-before &&
> +        write_script fake-editor.sh <<-\EOF &&
> +        true
> +        EOF
> +        test_set_editor "$(pwd)"/fake-editor.sh &&
> +        git history reword HEAD 2>err &&
> +        git rev-parse HEAD >oid-after &&
> +        test_cmp oid-before oid-after &&
> +        test_grep "Message unchanged" err
> +    )

> +'
> +
> test_done
> 
> --
> 2.54.0

> Having said that, I personally think that the current behaviour of
> `commit --amend` and `history reword` are both _wrong_ [*2*].
> 
> You may start `git commit --amend`, and after staring at the
> existing commit log message for some time in your editor, it is
> quite natural for you to decide that leaving the commit as-is is the
> right thing [*3*] in your situation.  It may have been a better
> design for the system to notice this situation and leave the commit
> as-is, with an override option `--force` to allow users to forcibly
> update the committer ident and timestamp in the commit header.  I am
> not a `history reword` user (yet), but from the motivation you
> described for this patch, I sense that the story is the same there.

> [Footnote]
> 
> *1* Besides, doesn't "--update-refs" in "rebase -i" allow you to
>     adjust the branches?
> 
> *2* But it is an established behaviour people _rely_ on, so even
>     though it may have been better if these commands behaved
>     differently, it probably is a bit too late to change it now.
> 
> *3* This includes the case where the original author is especially
>     difficult to work with and would complain any change to their
>     commits, even if the only change you made for them is a
>     typofix.  Fixing a small typo/grammo may not be worth your time
>     and unpleasant exchanges with them after touching their commit.

> Le 8 juin 2026 à 09:29, Pablo Sabater <pabloosabaterr@gmail.com> a écrit :
> 
> El lun, 8 jun 2026 a las 14:16, Junio C Hamano (<gitster@pobox.com>) escribió:
>> 
>> Pablo Sabater <pabloosabaterr@gmail.com> writes:
>> 
>>> Unlike `git commit --amend` and `git rebase -i`, `git history reword`
>>> doesn't print anything, this makes it feel empty for a porcelain command
>>> and hard to tell if the command did anything without using other
>>> commands like `git log <commit>` to check if the reword was done.
>>> 
>>> Print a message on successful rewords so the user has feedback about it.
>>> 
>>> Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com>
>>> ---
>>> builtin/history.c         |  4 ++++
>>> t/t3451-history-reword.sh | 14 ++++++++++++++
>>> 2 files changed, 18 insertions(+)
>>> 
>>> diff --git a/builtin/history.c b/builtin/history.c
>>> index 51a22a9a1c..0f1ba3b531 100644
>>> --- a/builtin/history.c
>>> +++ b/builtin/history.c
>>> @@ -739,6 +739,10 @@ static int cmd_history_reword(int argc,
>>>              goto out;
>>>      }
>>> 
>>> +     fprintf(stderr, _("Successfully reworded commit %s to %s\n"),
>>> +             repo_find_unique_abbrev(repo, &original->object.oid, DEFAULT_ABBREV),
>>> +             repo_find_unique_abbrev(repo, &rewritten->object.oid, DEFAULT_ABBREV));
>>> +
>>>      ret = 0;
>>> 
>>> out:
>> 
>> Do other commands in "git history" (split is in 'master', drop and
>> fixup are cooking) behave with similar verbosity?  Consistency within
>> the same "history" umbrella matters more than being similar with
>> other commands that can be used for similar purposes.
> 
> They do not, they are thought with the rule of silence in mind.
> However I think that this output is valuable information I might have
> explained myself better at [1] but my thought is:
> 
> git history reword aabb
> 
> Now that I have my commit aabb rewritten I want to check it again just
> to make sure I did what I wanted correctly,

> but git log aabb is still
> the old commit, the rewritten one has a different hash which I do not
> know unless I search for it, if it's far from HEAD I'd have to git log
> --oneline, get the hash and then git log new_hash. I think that git
> history reword that does have the information about the new hash
> should print it to avoid this search.
> What I want is something like:
> 
> git history reword aabb
> Successfully reworded aabb to ccdd
> 
> So I can just git log ccdd without having to search.
> 
> I want to say I haven't looked as much as I'd like to split, drop and
> fixup, but I think it would be a good addition for them also. On [1]
> Patrick wrote about a --verbose for git history, I think that the
> basic information i.e. at reword which is the new hash should be
> always printed but if it's preferred it could go there.
> 
> For split it can print the hashes of the new commits like:
> "...split into ccdd and eeff."
> For fixup the commit hash also changes, so the same as reword.
> The one that will have more friction would be drop is the one that
> doesn't end up with new commits.
> 
> [1]: https://lore.kernel.org/git/CAN5EUNSAOMRvmLGVfzQiwWoOn9VGNVU5rVMZizOryn_q2fbCNA@mail.gmail.com/

> > +test_expect_success 'aborts if the commit message is the same' '
> > +    test_when_finished "rm -rf repo" &&
> > +    git init repo &&
> > +    (
> > +        cd repo &&
> > +        test_commit first &&
> > +        test_commit second &&
> > +
> > +        git rev-parse HEAD >oid-before &&
> > +        write_script fake-editor.sh <<-\EOF &&
> > +        true
> > +        EOF
> > +        test_set_editor "$(pwd)"/fake-editor.sh &&
> > +        git history reword HEAD 2>err &&
> > +        git rev-parse HEAD >oid-after &&
> > +        test_cmp oid-before oid-after &&
> > +        test_grep "Message unchanged" err
> > +    )
>
> …but I think this test case could do something like "GIT_EDITOR=true git history reword HEAD" and avoid the script?

>
> > +'
> > +
> > test_done
> >
> > --
> > 2.54.0
>
> Best,
> Ben

>
>
> > Le 8 juin 2026 à 08:23, Junio C Hamano <gitster@pobox.com> a écrit :
> >
> [snip]
>
> > Having said that, I personally think that the current behaviour of
> > `commit --amend` and `history reword` are both _wrong_ [*2*].
> >
> > You may start `git commit --amend`, and after staring at the
> > existing commit log message for some time in your editor, it is
> > quite natural for you to decide that leaving the commit as-is is the
> > right thing [*3*] in your situation.  It may have been a better
> > design for the system to notice this situation and leave the commit
> > as-is, with an override option `--force` to allow users to forcibly
> > update the committer ident and timestamp in the commit header.  I am
> > not a `history reword` user (yet), but from the motivation you
> > described for this patch, I sense that the story is the same there.
>
> FWIW, in this situation I abort my editor (:cquit in Vim) so that the amend gets an error-valued exit code from the subprocess and aborts itself.
>
> Perhaps there could/should be a better side-channel for communicating that, though? I do not know how easy it is to tell other editors to « quit with errors ».

>
> > [Footnote]
> >
> > *1* Besides, doesn't "--update-refs" in "rebase -i" allow you to
> >     adjust the branches?
> >
> > *2* But it is an established behaviour people _rely_ on, so even
> >     though it may have been better if these commands behaved
> >     differently, it probably is a bit too late to change it now.
> >
> > *3* This includes the case where the original author is especially
> >     difficult to work with and would complain any change to their
> >     commits, even if the only change you made for them is a
> >     typofix.  Fixing a small typo/grammo may not be worth your time
> >     and unpleasant exchanges with them after touching their commit.

>
> `git rebase -i` may have an excuse that because it, unlike "git
> commit --amend", operates on multiple commits by design.  A single
> "--force" option given to the command would not have worked as an
> escape hatch to allow the user to tell the command "in this reword
> of this particular commit, I ended up doing nothing, but I still
> want an updated committer log timestamp".  Perhaps giving the
> "--force" (or --force-rewrite") option at "rebase --continue" time
> may work, but in any case, unless we plan to transition to these
> "better" default behaviour at a big version boundary, speculating
> what a "better" behaviour would have been may be fun but not very
> productive.
>
>
> [Footnote]
>
>  *1* Besides, doesn't "--update-refs" in "rebase -i" allow you to
>      adjust the branches?
>
>  *2* But it is an established behaviour people _rely_ on, so even
>      though it may have been better if these commands behaved
>      differently, it probably is a bit too late to change it now.
>
>  *3* This includes the case where the original author is especially
>      difficult to work with and would complain any change to their
>      commits, even if the only change you made for them is a
>      typofix.  Fixing a small typo/grammo may not be worth your time
>      and unpleasant exchanges with them after touching their commit.

> El lun, 8 jun 2026 a las 14:16, Junio C Hamano (<gitster@pobox.com>) escribió:
>>
> [snip]
>>
>> `git rebase -i` may have an excuse that because it, unlike "git
>> commit --amend", operates on multiple commits by design.  A single
>> "--force" option given to the command would not have worked as an
>> escape hatch to allow the user to tell the command "in this reword
>> of this particular commit, I ended up doing nothing, but I still
>> want an updated committer log timestamp".  Perhaps giving the
>> "--force" (or --force-rewrite") option at "rebase --continue" time
>> may work, but in any case, unless we plan to transition to these
>> "better" default behaviour at a big version boundary, speculating
>> what a "better" behaviour would have been may be fun but not very
>> productive.
>>
>>
>> [Footnote]
>>
>>  *1* Besides, doesn't "--update-refs" in "rebase -i" allow you to
>>      adjust the branches?
>>
>>  *2* But it is an established behaviour people _rely_ on, so even
>>      though it may have been better if these commands behaved
>>      differently, it probably is a bit too late to change it now.
>>
>>  *3* This includes the case where the original author is especially
>>      difficult to work with and would complain any change to their
>>      commits, even if the only change you made for them is a
>>      typofix.  Fixing a small typo/grammo may not be worth your time
>>      and unpleasant exchanges with them after touching their commit.
>
>[snip]
>
> About the --force sounds good to me. I could seek to implement it in
> this series if it's ok.

>   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;
> +		}

>   	} else {
>   		strbuf_addstr(&commit_message, original_body);
>   	}
> @@ -693,7 +701,8 @@ static int cmd_history_reword(int argc,
>   	struct strbuf reflog_msg = STRBUF_INIT;
>   	struct commit *original, *rewritten;
>   	struct rev_info revs = { 0 };
> -	enum commit_tree_flags flags = COMMIT_TREE_EDIT_MESSAGE;
> +	enum commit_tree_flags flags = COMMIT_TREE_EDIT_MESSAGE |
> +				       COMMIT_TREE_ABORT_ON_SAME_MESSAGE;
>   	int ret;
>   
>   	argc = parse_options(argc, argv, prefix, options, usage, 0);
> @@ -721,6 +730,9 @@ static int cmd_history_reword(int argc,
>   	if (ret < 0) {
>   		ret = error(_("failed writing reworded commit"));
>   		goto out;
> +	} else if (ret == 1) {
> +		ret = 0;
> +		goto out;
>   	}
>   
>   	strbuf_addf(&reflog_msg, "reword: updating %s", argv[0]);
> diff --git a/t/t3451-history-reword.sh b/t/t3451-history-reword.sh
> index de7b357685..6e0e278c42 100755
> --- a/t/t3451-history-reword.sh
> +++ b/t/t3451-history-reword.sh
> @@ -396,4 +396,20 @@ test_expect_success 'retains changes in the worktree and index' '
>   	)
>   '
>   
> +test_expect_success 'aborts if the commit message is the same' '
> +	test_when_finished "rm -rf repo" &&
> +	git init repo &&
> +	(
> +		cd repo &&
> +		test_commit first &&
> +		test_commit second &&
> +
> +		git rev-parse HEAD >oid-before &&
> +		GIT_EDITOR=true git history reword HEAD 2>err &&
> +		git rev-parse HEAD >oid-after &&
> +		test_cmp oid-before oid-after &&
> +		test_grep "Message unchanged" err
> +	)
> +'
> +
>   test_done
> diff --git a/t/t3453-history-fixup.sh b/t/t3453-history-fixup.sh
> index 868298e248..9f9a3c93de 100755
> --- a/t/t3453-history-fixup.sh
> +++ b/t/t3453-history-fixup.sh
> @@ -443,6 +443,28 @@ test_expect_success '--reedit-message opens editor for the commit message' '
>   	)
>   '
>   
> +test_expect_success 'fixup --reedit-message does not abort with the same commit message' '
> +	test_when_finished "rm -rf repo" &&
> +	git init repo &&
> +	(
> +		cd repo &&
> +		test_commit initial &&
> +		echo content > file.txt &&
> +		git add file.txt &&
> +		git commit -m "add file" &&
> +
> +		echo fix >>file.txt &&
> +		git add file.txt &&
> +		GIT_EDITOR=true git history fixup --reedit-message HEAD &&
> +		expect_changes --branches <<-\EOF
> +		add file
> +		2	0	file.txt
> +		initial
> +		1	0	initial.t
> +		EOF
> +	)
> +'
> +
>   test_expect_success 'retains unstaged working tree changes after fixup' '
>   	test_when_finished "rm -rf repo" &&
>   	git init repo &&
> 

>
> Pablo Sabater <pabloosabaterr@gmail.com> writes:
>
> > True, after reading it, history being more costly or the in memory are
> > not good args.
>
> And no argument, including that history is new, is a good excuse to
> make these three things inconsistent, period.
>
> One of the patches in your updated iteration claims
>
>     When using `git history reword <commit>` if the new message is the same
>     as the original, it continues and rewrites the history when nothing
>     changed.
>
>     `git commit --amend` and `git rebase -i` with reword share this behavior
>     and it is wrong as well, but changing them breaks what people are used
>     to. Take the opportunity of `git history` being a new command and handle
>     it correctly from the start.
>
> and I think this is a totally wrong attitude to go about this.
>
> I may have said that it may have been a better default to try hard
> to avoid making a change that is a no-op, other than that it changes
> committer timestamp, while making the current "always create a new
> commit object" behaviour optionally available, for these three
> commands, and cited that the behaviour of 'pick' in 'rebase -i' that
> avoids unnecessary rewrite as an example of a good practice.
>
> But I do not think the existing behaviour to always rewrite is
> *wrong* at all.  It may be wrong not to offer the other choice of
> pretending no content change means no commit object change, but that
> is a different story.
>
> I also do not think *aborting* only when the message happens to be
> the same is a valid mode of operation at all.
>
> The most sensible first step, I think, is to add a new command line
> option to "git history" (which will gain more history editing
> subcommands) that tells the command to leave the original history
> as-is when the only change rewriting commits would make would be to
> the committer ident or timestamp information.  If in a future a new
> replace-tree subcommand is added, e.g. if
>
>     $ git history replace-tree HEAD~20 HEAD~27^{tree}
>
> were a command to rewrite the history in such a way that 20th direct
> ancestor of the current HEAD had a tree object HEAD~27^{tree}, by
> derfault the command _should_ rewrite HEAD~10 and everything that
> has it as an ancestor.  With the "--avoid-unnecsssary-rewrite"
> optimization feature on, however, it may silently become a no-op
> when HEAD~27^{tree} happened to be the same tree as HEAD~20^{tree}
> so the only difference between rewritten and original HEAD~20 would
> be when that commit object was created and by whom.
>
> And give the same option to "rebase -i" or "commit --amend".  We can
> discuss, educate the users, and flip the default at a major version
> boundary, if the "avoid unnecessary rewrite" truly turns out to be a
> better default (right now it is merely our speculation, and we do
> not even know if the current behaviour is a worse default).

> 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.

>
> 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?

> 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 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.

> 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.

> Justin Tobler <jltobler@gmail.com> writes:
> 
> > 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.

> 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.

> 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?

> 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?

> 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?

>> They do not, they are thought with the rule of silence in mind.
>> However I think that this output is valuable information I might have
>> explained myself better at [1] but my thought is:
>> 
>> git history reword aabb
>> 
>> Now that I have my commit aabb rewritten I want to check it again just
>> to make sure I did what I wanted correctly,
>
> Some thoughts:
> 
> - If the rewritten commit is an ancestor of HEAD, look at the log of HEAD@{1} or the log between HEAD and the aforementioned reflog entry. (git-range-diff may also be helpful there.)
> - Similarly, if the rewritten commit is reachable from some ref R, check R@{1} etc. 

>
> [context: I just played with git history reword/fixup and dug through
> archives for anything like this, so chiming in.
> First, thanks for the new git history commands, they all look promising!]
>
> Ben Knoble wrote on Mon, Jun 08, 2026 at 12:47:41PM -0400:

> >> They do not, they are thought with the rule of silence in mind.
> >> However I think that this output is valuable information I might have
> >> explained myself better at [1] but my thought is:
> >>
> >> git history reword aabb
> >>
> >> Now that I have my commit aabb rewritten I want to check it again just
> >> to make sure I did what I wanted correctly,
> >
> > Some thoughts:
> >
> > - If the rewritten commit is an ancestor of HEAD, look at the log of HEAD@{1} or the log between HEAD and the aforementioned reflog entry. (git-range-diff may also be helpful there.)
> > - Similarly, if the rewritten commit is reachable from some ref R, check R@{1} etc.
>
> During my quick tests I was surprised with how git history reword/fixup
> behave with commits that aren't ancestors of HEAD/any branch (that can
> happen for example if you print `git log --oneline` once and refer to it
> after editing.

> This transcript is a bit ugly but should illustrate the issue:
> ```
> $ git init
> Initialized empty Git repository in ...test/.git/
> $ echo a > aa
> $ git add aa
> $ git commit -m init
> [master (root-commit) 62884dc4d43c] init
>  1 file changed, 1 insertion(+)
>  create mode 100644 aa
> $ echo b > b
> $ git add b
> $ git commit -m b
> [master 058294f87a36] b
>  1 file changed, 1 insertion(+)
>  create mode 100644 b
> $ echo c > c
> $ git add c
> $ git commit -m c
> [master 0c4ad0c9337c] c
>  1 file changed, 1 insertion(+)
>  create mode 100644 c
> $ git log --oneline --graph
> * 0c4ad0c9337c (HEAD -> master) c
> * 058294f87a36 b
> * 62884dc4d43c init
> $ echo d > d
> $ git add d
> $ git history fixup HEAD^
> $ echo e > e
> $ git add e
> $ git history fixup 058294f87a36
> $ git status
> On branch master
> Changes to be committed:
>   (use "git restore --staged <file>..." to unstage)
>         new file:   e
> $ git history reword 058294f87a36
> (editor showed up, commit message modified and saved)
> $ git log --oneline --graph
> * 5cc5551381a3 (HEAD -> master) c
> * 0b7ab36bf167 b
> * 62884dc4d43c init
> ```
> -> fixup didn't show any message (and exited with 0), but didn't unstage
> the hunk either and didn't do anything, so one cannot differentiate with
> the fixup actually happening
> -> reword showed up editor but didn't actually do anything visible
> (probably did create a new commit somewhere that's unreachable?)

> ... But it might be worth to ensure that the commit has any ref we can
> handle (if --update-refs is set then the commit we edit is ancestor to
> some branch, if not set then it must be an ancestor of HEAD)
>
> What do you think?

> > So I agree with Pablo's suggestion: printing old/new short hash on
> > success would help visualy confirming something worked.
> 
> I think we have the machinery for this (see --update-refs=print for
> git-replay, for example), but I'm surprised to learn that we don't
> accept --update-refs=print for history.
> 
> In any case, I second the "we should emit something"—I wonder what, though.
> 
> - In the case of rewritten refs, we might like to emit the list of
> rewrites, a bit like a fetch or push will do: "+ $old...$new $ref
> (forced update)" or something
> - For new objects that aren't pointed to… maybe silence is a better
> indicator that "we didn't do what you intended"? Or we could just
> print the new commit objects "$new [unreferenced object]" or something

> > ... But it might be worth to ensure that the commit has any ref we can
> > handle (if --update-refs is set then the commit we edit is ancestor to
> > some branch, if not set then it must be an ancestor of HEAD)
> >
> > What do you think?
> 
> I don't think it's worth restricting the operation (I can imagine a
> use case where someone creates an unpointed-to object and later makes
> the ref, even if that's a bit weird), but
> 
> - we could have a "strict" mode that ensured inputs are pointed to
> - we could warn when only unreferenced objects are rewritten
> 
> ? I see git-history as very "porcelain"/user-focused, so I think it's
> feasible to add output niceties (and optionally a quiet mode to
> suppress the messages).