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@xxxxxxxxx/ >> >> §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.
