From: Patrick Steinhardt Date: Mon, 08 Jun 2026 09:30:49 GMT Subject: Re: [PATCH RFC 2/2] builtin/history: print feedback after successful reword Message-ID: In-Reply-To: <20260607-ps-history-reword-v1-2-ba43a3cbb81b@gmail.com> 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 ` 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? - Why don't we print any of the other rewritten branches? - 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? 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