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