All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git List Mailing <git@vger.kernel.org>
Subject: Re: "git symbolic-ref" doesn't do a very good job
Date: Mon, 1 Aug 2022 10:49:26 -0700	[thread overview]
Message-ID: <CAHk-=wg8EaHnM_OcHrw=+sT3VPAkTUpzeaQ8EjTDLUENK58HSw@mail.gmail.com> (raw)
In-Reply-To: <YugPER9UsH1z6MZo@coredump.intra.peff.net>

)(

On Mon, Aug 1, 2022 at 10:36 AM Jeff King <peff@peff.net> wrote:
>
> No, sadly, that isn't the rule. See afe5d3d516 (symbolic ref: refuse
> non-ref targets in HEAD, 2009-01-29) which tightened it to "refs/heads"
> and then e9cc02f0e4 (symbolic-ref: allow refs/<whatever> in HEAD,
> 2009-02-13) which had to loosen it.

But it seems that at least this issue won't affect check_refname_format().

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 guess the only thing it disallows is literally HEAD and MERGE_HEAD
and the like. But it's a bit odd, because it would seem to possibly
allow you to use "refs" that point to the objects/ directory or
similar.

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

                Linus

  reply	other threads:[~2022-08-01 17:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-30 19:53 "git symbolic-ref" doesn't do a very good job Linus Torvalds
2022-07-30 20:21 ` Linus Torvalds
2022-07-30 20:38   ` Junio C Hamano
2022-07-31  0:18   ` Jeff King
2022-07-31  0:24     ` Jeff King
2022-07-31  0:44       ` Linus Torvalds
2022-08-01 17:43         ` Jeff King
2022-08-01 17:46           ` Jeff King
2022-08-01 18:15           ` Jeff King
2022-08-01 18:54             ` Junio C Hamano
2022-08-02  0:46               ` Jeff King
2022-08-02  0:57                 ` Junio C Hamano
2022-08-01 19:00             ` Linus Torvalds
2022-07-31 19:10     ` Junio C Hamano
2022-08-01 17:36       ` Jeff King
2022-08-01 17:49         ` Linus Torvalds [this message]
2022-08-01 18:04           ` Jeff King

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='CAHk-=wg8EaHnM_OcHrw=+sT3VPAkTUpzeaQ8EjTDLUENK58HSw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.