On Tue, Jul 7, 2026 at 1:09 AM Dominique Martinet
[off-list ref] wrote:

[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:

[snip]

quoted

quoted

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.

Indeed, this is a bit of a "trap":

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?)

I think what probably happened here (and what you might find with `git
fsck` for example) is that you have new commit objects in chains
corresponding to those operations, but no refs were rewritten.

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

I think we have the machinery for this (see --update-refs=print for
git-replay, for example), but I'm surprised to learn that we don't
accept --update-refs=print for history.

In any case, I second the "we should emit something"—I wonder what, though.

- In the case of rewritten refs, we might like to emit the list of
rewrites, a bit like a fetch or push will do: "+ $old...$new $ref
(forced update)" or something
- For new objects that aren't pointed to… maybe silence is a better
indicator that "we didn't do what you intended"? Or we could just
print the new commit objects "$new [unreferenced object]" or something

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

I don't think it's worth restricting the operation (I can imagine a
use case where someone creates an unpointed-to object and later makes
the ref, even if that's a bit weird), but

- we could have a "strict" mode that ensured inputs are pointed to
- we could warn when only unreferenced objects are rewritten

? I see git-history as very "porcelain"/user-focused, so I think it's
feasible to add output niceties (and optionally a quiet mode to
suppress the messages).

-- 
D. Ben Knoble