On Tue, Jul 07, 2026 at 12:10:12PM -0400, D. Ben Knoble wrote:

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

[snip]

quoted

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

That's exactly my issue, as well. I'm slightly in favor of not writing
anything, but if we're able to figure out how exactly to represent
results to users in a nice and consistent way then I'm very happy to
change my opinion.

But that definitely needs to account not only for the case where the
current HEAD gets rewritten, but it needs to account for any reference
(including detached HEAD) that may be updated along the way.

quoted

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

Yeah, I don't see any issue with having such a "strict" mode, either.
But I definitely don't want to enforce "arbitrary" restrictions that
require the user to work around them. It's intentional that you can
rewrite history of commits that aren't even reachable from HEAD.

It might be sensible to even make the strict mode the default, where you
need to pass a switch to rewrite commits that are not reachable from
HEAD. But if so, we need to have a switch that disables this mode.

Patrick