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

From: Dominique Martinet <asmadeus@codewreck.org>
Date: Jul 7, 2026, 05:09 UTC
Message-ID: <akyKDtuHTHZGEpFx@codewreck.org>
In-Reply-To: <9C91B027-C24A-4D7B-A3BC-5CF3B04D990C@gmail.com>

[context: I just played with git history reword/fixup and dug through archives for anything like this, so chiming in. First, thanks for the new git history commands, they all look promising!]

Ben Knoble wrote on Mon, Jun 08, 2026 at 12:47:41PM -0400:

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

I agree with the sentiment of needing consistency, but rather than say "the other commands are not verbose" (as they are) I'd say they're new enough we can afford to "make them all verbose" instead.

In particular, for git history reword there is an editor opening up, so I didn't have much trouble assuming silence was success, but I was disturbed by `git history fixup` which just returns immediately (much faster than rebase) with no feedback at all.

Show 13 quoted lines

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

During my quick tests I was surprised with how git history reword/fixup behave with commits that aren't ancestors of HEAD/any branch (that can happen for example if you print `git log --oneline` once and refer to it after editing.

This transcript is a bit ugly but should illustrate the issue:
```
$ git init
Initialized empty Git repository in ...test/.git/
$ echo a > aa
$ git add aa
$ git commit -m init
[master (root-commit) 62884dc4d43c] init
 1 file changed, 1 insertion(+)
 create mode 100644 aa
$ echo b > b
$ git add b
$ git commit -m b
[master 058294f87a36] b
 1 file changed, 1 insertion(+)
 create mode 100644 b
$ echo c > c
$ git add c
$ git commit -m c
[master 0c4ad0c9337c] c
 1 file changed, 1 insertion(+)
 create mode 100644 c
$ git log --oneline --graph
* 0c4ad0c9337c (HEAD -> master) c
* 058294f87a36 b
* 62884dc4d43c init
$ echo d > d
$ git add d
$ git history fixup HEAD^
$ echo e > e
$ git add e
$ git history fixup 058294f87a36
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	new file:   e
$ git history reword 058294f87a36
(editor showed up, commit message modified and saved)
$ git log --oneline --graph
* 5cc5551381a3 (HEAD -> master) c
* 0b7ab36bf167 b
* 62884dc4d43c init
```
-> fixup didn't show any message (and exited with 0), but didn't unstage
the hunk either and didn't do anything, so one cannot differentiate with
the fixup actually happening
-> reword showed up editor but didn't actually do anything visible
(probably did create a new commit somewhere that's unreachable?)

So I agree with Pablo's suggestion: printing old/new short hash on success would help visualy confirming something worked.

... But it might be worth to ensure that the commit has any ref we can handle (if --update-refs is set then the commit we edit is ancestor to some branch, if not set then it must be an ancestor of HEAD)

What do you think?

-- 
Dominique Martinet | Asmadeus