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

From: Jeff King <peff@peff.net>
Date: Aug 1, 2022, 18:04 UTC
Message-ID: <YugVxaej5LdX4S8r@coredump.intra.peff.net>
In-Reply-To: <CAHk-=wg8EaHnM_OcHrw=+sT3VPAkTUpzeaQ8EjTDLUENK58HSw@mail.gmail.com>

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

Show 8 quoted lines

> 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