From: Ben Knoble <ben.knoble@gmail.com>
Date: Mon, 08 Jun 2026 16:47:41 GMT
Subject: Re: [PATCH RFC 2/2] builtin/history: print feedback after successful reword
Message-ID: <9C91B027-C24A-4D7B-A3BC-5CF3B04D990C@gmail.com>
In-Reply-To: <CAN5EUNQNj86Q+hi6PouOZNWo1T4QTQ6sE5Hs9USZXWpkTedTcw@mail.gmail.com>


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

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. 

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