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.
next prev parent 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).