Thread (4 messages) 4 messages, 3 authors, 2022-08-01

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

From: Jeff King <hidden>
Date: 2022-08-01 18:04:59

Possibly related (same subject, not in this thread)

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help