git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH RFC 2/2] builtin/history: print feedback after successful reword

From
Pablo Sabater <pabloosabaterr@gmail.com>
Date
Jun 8, 2026, 13:23 UTC
Message-ID
<CAN5EUNQNj86Q+hi6PouOZNWo1T4QTQ6sE5Hs9USZXWpkTedTcw@mail.gmail.com>
In-Reply-To
<xmqqqzmhz0pq.fsf@gitster.g>
El lun, 8 jun 2026 a las 14:16, Junio C Hamano (<gitster@pobox.com>) escribió:
Show 36 quoted lines
>
> 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/
Show 24 quoted lines
>
> > 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
Previous: Junio C HamanoNext: Ben Knoble
Message 18 of 36 in “builtin/history: change git history reword behavior and feedback”
  1. 0/2 builtin/history: change git history reword behavior and feedbackPablo Sabater, Jun 7, 2026
  2. 1/2 builtin/history: abort reword on unchanged messagePablo Sabater, Jun 7, 2026
  3. Patrick SteinhardtJun 8, 2026
  4. Pablo SabaterJun 8, 2026
  5. Junio C HamanoJun 8, 2026
  6. Ben KnobleJun 8, 2026
  7. Pablo SabaterJun 9, 2026
  8. Pablo SabaterJun 9, 2026
  9. Kristoffer HaugsbakkJun 9, 2026
  10. Junio C HamanoJun 9, 2026
  11. Pablo SabaterJun 9, 2026
  12. Ben KnobleJun 8, 2026
  13. Pablo SabaterJun 9, 2026
  14. 2/2 builtin/history: print feedback after successful rewordPablo Sabater, Jun 7, 2026
  15. Patrick SteinhardtJun 8, 2026
  16. Pablo SabaterJun 8, 2026
  17. Junio C HamanoJun 8, 2026
  18. Pablo SabaterJun 8, 2026
  19. Ben KnobleJun 8, 2026
  20. Dominique MartinetJul 7, 2026
  21. D. Ben KnobleJul 7, 2026
  22. Patrick SteinhardtJul 8, 2026
  23. 0/2 builtin/history: abort reword on same messagePablo Sabater, Jun 9, 2026
  24. 1/2 builtin/history: refactor function signaturePablo Sabater, Jun 9, 2026
  25. 2/2 builtin/history: abort reword on same messagePablo Sabater, Jun 9, 2026
  26. Phillip WoodJun 9, 2026
  27. Junio C HamanoJun 9, 2026
  28. Pablo SabaterJun 9, 2026
  29. Junio C HamanoJun 9, 2026
  30. Patrick SteinhardtJun 10, 2026
  31. Phillip WoodJun 10, 2026
  32. Junio C HamanoJun 10, 2026
  33. Justin ToblerJun 9, 2026
  34. Junio C HamanoJun 9, 2026
  35. Justin ToblerJun 9, 2026
  36. Phillip WoodJun 10, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.