Re: [PATCH 6/8] check_refname_format(): add FULLY_QUALIFIED flag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 30, 2024 at 05:47:38AM -0400, Jeff King wrote:
> On Mon, Apr 29, 2024 at 09:01:52AM -0700, Karthik Nayak wrote:
> 
> > Jeff King <peff@xxxxxxxx> writes:
> > 
> > > Before operating on a refname we get from a user, we usually check that
> > > it's syntactically valid. As a general rule, refs should be in the
> > > "refs/" namespace, the exception being HEAD and pseudorefs like
> > > FETCH_HEAD, etc. Those pseudorefs should consist only of all-caps and
> > > dash. But the syntactic rules are not enforced by check_refname_format().
> > 
> > Nit: s/dash/underscore
> 
> Oops, yes. Will fix (and the same mistake in patch 8). Thanks.
> 
> > Also FETCH_HEAD is a special_ref, this confusion should however be
> > resolved with Patrick's patches [1].
> 
> Hmph, I guess I was not paying attention and missed that the distinction
> even existed. But yeah, I think for the purposes here it is not at all
> important. This is purely about the syntax rules, which are the same for
> HEAD, pseudorefs, and special refs.

Agreed. I'll send out a complete rewrite of that patch series in a bit
where I drop the distinction of special and pseudo refs completely. From
thereon, pseudo refs return to their original meaning, which is a file
that is not a ref, but that can be parsed as a ref via git-rev-parse(1).

I think that the current state of refs, special refs, root refs, pseudo
refs and head refs is not something that anybody can reasonably
understand without studying our ref code for months. And I did study it
for months now and still feel like I don't always get the full picture.

Patrick

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux