From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Tue, 07 Jul 2026 16:10:12 GMT
Subject: Re: [PATCH RFC 2/2] builtin/history: print feedback after successful reword
Message-ID: <CALnO6CAjZfK3hPWn1vOxgw=4=cjRYEHabYJmJrpVVDU8yyQn_g@mail.gmail.com>
In-Reply-To: <akyKDtuHTHZGEpFx@codewreck.org>

On Tue, Jul 7, 2026 at 1:09 AM Dominique Martinet
<asmadeus@codewreck.org> 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]
> >> 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