From: Patrick Steinhardt <ps@pks.im>
To: Jeff King <peff@peff.net>
Cc: Karthik Nayak <karthik.188@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 6/8] check_refname_format(): add FULLY_QUALIFIED flag
Date: Tue, 30 Apr 2024 12:05:43 +0200 [thread overview]
Message-ID: <ZjDCd3z1MeFlvh7Q@tanuki> (raw)
In-Reply-To: <20240430094738.GA1279403@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]
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@peff.net> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-04-30 10:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-29 8:33 [PATCH 6/8] check_refname_format(): add FULLY_QUALIFIED flag Jeff King
2024-04-29 16:01 ` Karthik Nayak
2024-04-30 9:47 ` Jeff King
2024-04-30 10:05 ` Patrick Steinhardt [this message]
2024-04-30 4:54 ` Patrick Steinhardt
2024-04-30 10:01 ` Jeff King
2024-04-30 10:09 ` Patrick Steinhardt
2024-04-30 17:00 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZjDCd3z1MeFlvh7Q@tanuki \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=karthik.188@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.