[PATCH] t1402: test forbidden characters in refnames

[PATCH] t1402: test forbidden characters in refnames

[Nikolaus Schuetz via GitGitGadget]

From: Nikolaus Schuetz <nikolauspschuetz@gmail.com>

git-check-ref-format(1) documents that a refname cannot contain a
space, tilde, caret, colon, question-mark, asterisk or open-bracket,
and that it cannot be the single character "@".  Of these, only "?"
was tested as a character embedded in an otherwise-valid refname;
"*" was checked only as a lone character or with --refspec-pattern.

Add the remaining forbidden characters in that embedded form, and
check that "@" alone is rejected even with --allow-onelevel -- where
"@" is otherwise a valid refname component, as "refs/@" confirms.

Signed-off-by: Nikolaus Schuetz <nikolauspschuetz@gmail.com>
---
    t1402: test forbidden characters in refnames
    
    git-check-ref-format(1) documents the characters that a refname may not
    contain (space, tilde, caret, colon, question-mark, asterisk,
    open-bracket) and the rule that it may not be the single character "@".
    t1402 only exercised a few of these directly.
    
    This adds the remaining forbidden characters in embedded form, and
    checks that "@" alone is rejected even with --allow-onelevel, where "@"
    is otherwise a valid refname component (as "refs/@" confirms).
    
    Test-only; documents existing behaviour, in the spirit of 919eb8ace
    (t1402: check for refs ending with a dot).

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2203%2Fnikolauspschuetz%2Fns%2Ft1402-forbidden-characters-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2203/nikolauspschuetz/ns/t1402-forbidden-characters-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2203

 t/t1402-check-ref-format.sh | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
index cabc516ae9..bc1e878a0f 100755
--- a/t/t1402-check-ref-format.sh
+++ b/t/t1402-check-ref-format.sh
@@ -51,12 +51,20 @@ invalid_ref '.refs/foo'
 invalid_ref 'refs/heads/foo.'
 invalid_ref 'heads/foo..bar'
 invalid_ref 'heads/foo?bar'
+invalid_ref 'heads/foo~bar'
+invalid_ref 'heads/foo^bar'
+invalid_ref 'heads/foo:bar'
+invalid_ref 'heads/foo*bar'
+invalid_ref 'heads/foo[bar'
+invalid_ref 'heads/foo bar'
 valid_ref 'foo./bar'
 invalid_ref 'heads/foo.lock'
 invalid_ref 'heads///foo.lock'
 invalid_ref 'foo.lock/bar'
 invalid_ref 'foo.lock///bar'
 valid_ref 'heads/foo@bar'
+valid_ref 'refs/@'
+invalid_ref '@' --allow-onelevel
 invalid_ref 'heads/v@{ation'
 invalid_ref 'heads/foo\bar'
 invalid_ref "$(printf 'heads/foo\t')"

base-commit: 745601a9a94110d74769ab605ccd4f61339758d2
-- 
gitgitgadget

Re: [PATCH] t1402: test forbidden characters in refnames

[Patrick Steinhardt]

On Thu, Aug 13, 2026 at 08:43:56PM +0000, Nikolaus Schuetz via GitGitGadget wrote:
> From: Nikolaus Schuetz <nikolauspschuetz@gmail.com>
> 
> git-check-ref-format(1) documents that a refname cannot contain a
> space, tilde, caret, colon, question-mark, asterisk or open-bracket,
> and that it cannot be the single character "@".  Of these, only "?"
> was tested as a character embedded in an otherwise-valid refname;
> "*" was checked only as a lone character or with --refspec-pattern.
> 
> Add the remaining forbidden characters in that embedded form, and
> check that "@" alone is rejected even with --allow-onelevel -- where
> "@" is otherwise a valid refname component, as "refs/@" confirms.

Okay.

> diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
> index cabc516ae9..bc1e878a0f 100755
> --- a/t/t1402-check-ref-format.sh
> +++ b/t/t1402-check-ref-format.sh
> @@ -51,12 +51,20 @@ invalid_ref '.refs/foo'
>  invalid_ref 'refs/heads/foo.'
>  invalid_ref 'heads/foo..bar'
>  invalid_ref 'heads/foo?bar'
> +invalid_ref 'heads/foo~bar'
> +invalid_ref 'heads/foo^bar'
> +invalid_ref 'heads/foo:bar'
> +invalid_ref 'heads/foo*bar'
> +invalid_ref 'heads/foo[bar'
> +invalid_ref 'heads/foo bar'

This feels a tiny bit excessive, but I guess it does not hurt to enforce
this property, especially now that it's so easy to add new backends.

One thing I was briefly wondering is whether we could maybe have a
simple loop here, as this feels quite repetitive. We could for example:

    for c in '?' '~' '^' ':' '*' '[' ' '
    do
        invalid_ref "heads/foo${c}bar"
    done

By the way, one weird bit: is it intentional that all of these really
use "heads/something" instead of "refs/heads/something"? I guess it
ultimately doesn't matter.

>  valid_ref 'foo./bar'
>  invalid_ref 'heads/foo.lock'
>  invalid_ref 'heads///foo.lock'
>  invalid_ref 'foo.lock/bar'
>  invalid_ref 'foo.lock///bar'
>  valid_ref 'heads/foo@bar'
> +valid_ref 'refs/@'
> +invalid_ref '@' --allow-onelevel

This one certainly is a good addition, as these are quite a bit more
subtle.

Thanks!

Patrick

Re: [PATCH] t1402: test forbidden characters in refnames

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> On Thu, Aug 13, 2026 at 08:43:56PM +0000, Nikolaus Schuetz via GitGitGadget wrote:
>> From: Nikolaus Schuetz <nikolauspschuetz@gmail.com>
>> 
>> git-check-ref-format(1) documents that a refname cannot contain a
>> space, tilde, caret, colon, question-mark, asterisk or open-bracket,
>> and that it cannot be the single character "@".  Of these, only "?"
>> was tested as a character embedded in an otherwise-valid refname;
>> "*" was checked only as a lone character or with --refspec-pattern.
>> 
>> Add the remaining forbidden characters in that embedded form, and
>> check that "@" alone is rejected even with --allow-onelevel -- where
>> "@" is otherwise a valid refname component, as "refs/@" confirms.
>
> Okay.
>
>> diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
>> index cabc516ae9..bc1e878a0f 100755
>> --- a/t/t1402-check-ref-format.sh
>> +++ b/t/t1402-check-ref-format.sh
>> @@ -51,12 +51,20 @@ invalid_ref '.refs/foo'
>>  invalid_ref 'refs/heads/foo.'
>>  invalid_ref 'heads/foo..bar'
>>  invalid_ref 'heads/foo?bar'
>> +invalid_ref 'heads/foo~bar'
>> +invalid_ref 'heads/foo^bar'
>> +invalid_ref 'heads/foo:bar'
>> +invalid_ref 'heads/foo*bar'
>> +invalid_ref 'heads/foo[bar'
>> +invalid_ref 'heads/foo bar'
>
> This feels a tiny bit excessive, but I guess it does not hurt to enforce
> this property, especially now that it's so easy to add new backends.

"Why would we even care to check these insane cases?" was my first
reaction, but I agree with you that these are to protect authors of
new backends from stupid mistakes.

> One thing I was briefly wondering is whether we could maybe have a
> simple loop here, as this feels quite repetitive. We could for example:
>
>     for c in '?' '~' '^' ':' '*' '[' ' '
>     do
>         invalid_ref "heads/foo${c}bar"
>     done

True.  And c does not have to be a single byte. ".." can also be
part of the repertoire.

> By the way, one weird bit: is it intentional that all of these really
> use "heads/something" instead of "refs/heads/something"? I guess it
> ultimately doesn't matter.
>
>>  valid_ref 'foo./bar'
>>  invalid_ref 'heads/foo.lock'
>>  invalid_ref 'heads///foo.lock'
>>  invalid_ref 'foo.lock/bar'
>>  invalid_ref 'foo.lock///bar'
>>  valid_ref 'heads/foo@bar'
>> +valid_ref 'refs/@'
>> +invalid_ref '@' --allow-onelevel
>
> This one certainly is a good addition, as these are quite a bit more
> subtle.
>
> Thanks!
>
> Patrick

Re: [PATCH] t1402: test forbidden characters in refnames

[Nikolaus Schuetz]

> True.  And c does not have to be a single byte. ".." can also be
> part of the repertoire.

Agreed and updated accordingly: forbidden chars are looped over,
and I folded ".." in along with "\" (the same forbidden-char list).
The other refname rules enforced by refs.c are well covered,
so I kept the loop to the embedded forbidden tokens.

> By the way, one weird bit: is it intentional that all of these really
> use "heads/something" instead of "refs/heads/something"?

Not intentional -- the file already mixes them (e.g. 'refs/heads/foo.'
vs 'heads/foo..bar'). check-ref-format validates each component
regardless of a refs/ prefix, so it doesn't change what's tested; I
kept 'heads/' to match the neighbours.

Thanks,
Nikolaus