git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Kristoffer Haugsbakk" <code@khaugsbakk.name>
To: shejialuo <shejialuo@gmail.com>
Cc: git@vger.kernel.org, "Jeff King" <peff@peff.net>,
	"Junio C Hamano" <gitster@pobox.com>
Subject: Re: [PATCH 0/3] object-name: don't allow @ as a branch name
Date: Tue, 08 Oct 2024 16:19:10 +0200	[thread overview]
Message-ID: <3af78a3c-afb9-4ce7-aea0-a5bbddd4f34a@app.fastmail.com> (raw)
In-Reply-To: <ZwUxdz_HobRGF9yq@ArchLinux>

On Tue, Oct 8, 2024, at 15:19, shejialuo wrote:
> On Mon, Oct 07, 2024 at 10:15:16PM +0200, Kristoffer Haugsbakk wrote:
>
> [snip]
>
>>   §2 Disallow `HEAD` as a branch name
>> 
>> This was done later in 2017:
>> 
>> https://lore.kernel.org/git/20171114114259.8937-1-kaartic.sivaraam@gmail.com/
>> 
>>   §2 `refs/heads/@` is apparently disallowed by git-refs(1)
>> 
>> See `t/t1508-at-combinations.sh`:
>> 
>> ```
>> error: refs/heads/@: badRefName: invalid refname format
>> ```
>> 
>
> It's true that using "git refs verify" will report "refs/heads/@" is a
> bad refname.
>
> From the man page of the "git-check-ref-format(1)", it is clear that
>
>     9. They cannot be the single character @.
>
> Because I am interesting in this patch which is highly relevant with my
> recent work, so I try somethings here and find some interesting results
> as below shows.
>
>     $ git check-ref-format refs/heads/@
>     $ echo $? # will be 0
>     # git check-ref-format --allow-onelevel @
>     # echo $? # will be 1
>
> The reason why "git refs verify" will report this error is that in the
> code implementation, I have to iterate every file in the filesystem. So
> it's convenient for me to do the following:
>
>     if (check_refname_format(iter->basename, REFNAME_ALLOW_ONELEVEL)) {
>         ret = fsck_report(...);
>     }
>
> Because I specify "REFNAME_ALLOW_ONELEVEL" here, so it will follow the
> "git check-ref-format --allow-onelevel" command thus reporting an error
> to the user.
>
> I am curious why "git check-ref-format refs/heads/@" will succeed, so I
> try to use "git symbolic-ref" and "git update-ref" to verify to test the
> behavior.
>
>     $ git symbolic-ref refs/heads/@ refs/heads/master
>     error: cannot lock ref 'refs/heads/@': unable to resolve reference 
> 'refs/heads/@': reference broken
>     $ git update-ref refs/heads/@ refs/heads/master
>     fatal: update_ref failed for ref 'refs/heads/@': cannot lock ref 
> 'refs/heads/@': unable to resolve reference 'refs/heads/@': reference 
> broken
>
> So, we are not consistent here. I guess the reason why "git
> check-ref-format refs/heads/@" will succeed is that we allow user create
> this kind of branch.
>
> If we decide to not allow user to create such refs. We should also
> change the behavior of the "check_refname_format" function. (I am not
> familiar with the internal implementation, this is my guess)
>
> Thanks,
> Jialuo

Thanks for the careful analysis.

  reply	other threads:[~2024-10-08 14:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-07 20:15 [PATCH 0/3] object-name: don't allow @ as a branch name Kristoffer Haugsbakk
2024-10-07 20:15 ` [PATCH 1/3] object-name: fix whitespace Kristoffer Haugsbakk
2024-10-07 20:15 ` [PATCH 2/3] object-name: don't allow @ as a branch name Kristoffer Haugsbakk
2024-10-07 20:44   ` Jeff King
2024-10-07 20:56     ` Kristoffer Haugsbakk
2024-10-08  6:52       ` Jeff King
2024-10-08 20:37     ` Rubén Justo
2024-10-07 22:01   ` Junio C Hamano
2024-10-08  6:54     ` Jeff King
2024-10-07 20:15 ` [PATCH 3/3] t1402: exercise disallowed branch names Kristoffer Haugsbakk
2024-10-07 20:47   ` Jeff King
2024-10-07 20:37 ` [PATCH 0/3] object-name: don't allow @ as a branch name Jeff King
2024-10-07 20:40   ` Kristoffer Haugsbakk
2024-10-08 13:19 ` shejialuo
2024-10-08 14:19   ` Kristoffer Haugsbakk [this message]
2024-10-18 14:21     ` shejialuo
2024-10-08 18:17   ` Junio C Hamano
2024-10-09 12:00     ` shejialuo

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=3af78a3c-afb9-4ce7-aea0-a5bbddd4f34a@app.fastmail.com \
    --to=code@khaugsbakk.name \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=shejialuo@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).