Re: "git symbolic-ref" doesn't do a very good job

[Jeff King <peff@peff.net>]

On Mon, Aug 01, 2022 at 10:49:26AM -0700, Linus Torvalds wrote:

> Hmm. Looking at that again - even without ALLOW_ONELEVEL I don't
> actually think check_refname_format() requires "refs/" per se. So the
> HEAD check isn't actually made redundant.
> 
> I wonder what the intended semantic meaning of ALLOW_ONELEVEL really
> is supposed to be. It seems to really only require *one* slash - but
> it doesn't really end up checking that it's in the "refs/" hierarchy,
> it can be anywhere.

I'm actually not that surprised. I think the history of that flag
is...weird. I think once upon a time, there was "one-level" checking
which was meant to disallow "refs/foo" versus "refs/heads/foo". But
there were also spots that wanted to make sure we were in refs/, and not
touching MERGE_HEAD, etc.

And because of the generic-ness of the flag name, those two cases got
conflated. I think it's mostly been sorted out over the years, but I
won't be surprised if there are weird corner cases.

> Maybe the refs/ protection comes in somewhere later, I didn't really
> go around to check.

I didn't check where, but I did confirm that the "symbolic-ref HEAD foo"
case in t1401 continues to pass even if we remove the special HEAD code.
So _something_ is doing it. ;)

-Peff