Thanks, that makes sense.

I was reasoning about reflog entries purely in terms of reference
updates, but I see your point that "git reset" also uses the reflog
as a record of user actions, even when the target happens to match
HEAD.

In that light, skipping the reflog entry on a no-op reset could indeed
break the assumption that "@{1}" reliably refers to "the state before
the most recent reset", both for scripts and for humans inspecting
history.

I agree that this makes the change questionable as-is. I’m happy to
drop this patch, or to rework it in a way that preserves the reflog
entry while addressing the underlying concern (if there is one).

Thanks for the detailed explanation.