This short series aims to improve the behavior of `git history reword`
to abort when the new commit message is the same as the original,
avoiding unnecessary history rewrites.

`git commit --amend` and `git rebase -i` with reword share this flaw but
changing them faces not just technical challenges but also breaks what
people are used to, so that is not a viable option. Let's take the
opportunity that `git history` is a new command and handle this
correctly from the start.

This is made so any other future subcommand or option that does want
this behavior just has to add the abort flag.

A questions I have is why don't we want this abort behavior on
`git history fixup --reedit-message` it makes more sense on
`git history reword` because if the message is the same then it has
nothing to do while fixup can still have files to update, but
--reedit-message is still a redundant option there.

Signed-off-by: Pablo Sabater <redacted>
---
Changes in v2:
- Changed the reason on why is this needed.
- Changed tests with same message to use GIT_EDITOR=true instead of the
  script.
- Abort on same message only happens when its own flag is set so no
  other subcommand that does not want this behavior and depend on
  commit_tree_ext() is affected.
- Dropped the feedback on successful reword for another series.

---
Pablo Sabater (2):
      builtin/history: refactor function signature
      builtin/history: abort reword on same message

 builtin/history.c         | 21 ++++++++++++++++++---
 t/t3451-history-reword.sh | 16 ++++++++++++++++
 t/t3453-history-fixup.sh  | 22 ++++++++++++++++++++++
 3 files changed, 56 insertions(+), 3 deletions(-)
---
base-commit: 9ac3f193c05c2237e2b14ebaa1149e9fc8a1abe0
change-id: 20260607-ps-history-reword-fcb70eaa4aa9

Best regards,
--  
Pablo Sabater [off-list ref]