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

El lun, 8 jun 2026 a las 11:30, Patrick Steinhardt ([off-list ref]) escribió:

On Sun, Jun 07, 2026 at 10:07:21PM +0200, Pablo Sabater wrote:

quoted

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

But neither `git commit --amend` nor `git rebase -i` follow this rule
of silence.

quoted

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?

Because `git history reword <commit>` is for a single commit. After
the reword the hash changes and the original hash is no longer useful
to check the rewritten message. If I want to see how it is now:

  $ git history reword aabb
  $ git log aabb <- I can't check how it is now because this is the old one

So to check the new one I have to search the new hash. Imagine if it's
the first of 20 long commit messages, I have to git log --oneline, get
the hash and then git log new_hash, which IMO is unnecessary when git
history reword can output the new hash.

  - Why don't we print any of the other rewritten branches?

Haven't thought of that, it's nice that it does modify all branches, I
just assumed that the most relevant is the current branch new commit
hash. The other rewritten branches have the same commit message, just
different hashes.

  - What makes "git history reword" so special as compared to for
    example "git history fixup" or "git history split" so that it needs
    a message while the others don't?

Nothing, I just wanted this specifically for reword and sent this very
simple as an RFC to discuss the idea, I could extend this where it
fits.

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.

I like the verbose mode idea but I still think that on non-verbose
something should be printed, on verbose it could be printed
additionally all the rewritten commits (though it could get very
noisy), the changed HEAD, etc.

Thanks!

Patrick

[1]: https://www.linfo.org/rule_of_silence.html

--
Pablo