On Tue, Aug 19, 2025 at 12:59:47PM -0400, Jeff King wrote:

On Tue, Aug 19, 2025 at 10:05:19AM +0200, Patrick Steinhardt wrote:

quoted

quoted

I didn't include a test here because it requires corrupting the
repository in a way that is only easy to do using the files ref backend.
It doesn't seem worth carrying a REFFILES test just for this oddity.

True:

    $ git update-ref HEAD HEAD^{tree}
    fatal: update_ref failed for ref 'HEAD': trying to write non-commit object 4b825dc642cb6eb9a060e54bf8d69288fbee4904 to branch 'HEAD'

But:

    $ git update-ref refs/some/tree HEAD^{tree}
    $ git symbolic-ref HEAD refs/some/tree
    $ git show
    tree HEAD

So that should allow you to write a test, right?

Hrm, that seems like a bug. I thought we insisted that HEAD point at
refs/heads.

Ah, no. We did that in b229d18a80 (validate_headref: tighten
ref-matching to just branches, 2009-01-29), but had to revert it in
e9cc02f0e4 (symbolic-ref: allow refs/<whatever> in HEAD, 2009-02-13) to
keep compatibility for topgit. :(

Well, that's certainly from before my time in the Git project :) I guess
changing semantics now would be quite risky. Reintroducing this change
feels out of the picture, but an alternative one could think about is to
validate that HEAD always points to a commit(-ish?).

But ultimately I'm not sure it's even worth it. If people really want to
shoot themselves into the foot they'll find a way to do so.

Still, I'm not sure it's something I'd want to base a test on. Maybe if
there is a big comment that says "It is OK to invalidate and remove this
test if we ever tighten symbolic-ref" it would be OK?

That sounds reasonable to me, yeah.

Patrick