{"thread":{"id":"56522","subject":"Should `@` be really a valid git tag name?","startedAt":"2021-09-17T11:20:34Z","lastAt":"2021-09-18T13:45:20Z","messageCount":10,"participants":["gitmailinglist.bentolor@xoxy.net","Carlo Arenas","Junio C Hamano","Jeff King","Carlo Marcelo Arenas Belón","Chris Torek"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"436224","messageId":"0c68d628-e093-1cbd-e3bd-38a827545418@gmx.net","threadId":"56522","inReplyTo":null,"subject":"Should `@` be really a valid git tag name?","fromName":"","fromEmail":"gitmailinglist.bentolor@xoxy.net","sentAt":"2021-09-17T11:20:19Z","receivedAt":"2021-09-17T11:20:34Z","isPatch":false,"sender":{"key":"gitmailinglist.bentolor@xoxy.net","avatar":null},"body":"Hello Git-Community,\n\nby accident I did:\n\n git tag -a -s @\n git push --tags\n\nin v2.25.1 and pushed the tag named `@` to Github and had some minutes\nof fun to get rid of it again (see: https://stackoverflow.com/a/69211383)\n\nA SO commenter pointed out, that git-check-ref-format forbids @ and\nmaybe I should report this as potential bug. Is it?\n\n\nBest,\nBenjamin\n\nP.S.: I'm not subscribed, so please CC me.\n\n"},{"id":"436243","messageId":"CAPUEspjbiNtffXatzNUUFYyZKRjcqetOTVqQX+MgZf_AJq9hnA@mail.gmail.com","threadId":"56522","inReplyTo":"0c68d628-e093-1cbd-e3bd-38a827545418@gmx.net","subject":"Re: Should `@` be really a valid git tag name?","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2021-09-17T18:20:14Z","receivedAt":"2021-09-17T18:20:29Z","isPatch":false,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Fri, Sep 17, 2021 at 7:12 AM wrote:\n>\n> A SO commenter pointed out, that git-check-ref-format forbids @ and\n> maybe I should report this as a potential bug. Is it?\n\na reference that is named \"@\" only is invalid, but refs/tags/@ is not.\n\nCarlo\n"},{"id":"436258","messageId":"xmqq4kaihqjj.fsf@gitster.g","threadId":"56522","inReplyTo":"CAPUEspjbiNtffXatzNUUFYyZKRjcqetOTVqQX+MgZf_AJq9hnA@mail.gmail.com","subject":"Re: Should `@` be really a valid git tag name?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-09-17T20:53:52Z","receivedAt":"2021-09-17T20:53:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlo Arenas writes:\n\n> On Fri, Sep 17, 2021 at 7:12 AM wrote:\n>>\n>> A SO commenter pointed out, that git-check-ref-format forbids @ and\n>> maybe I should report this as a potential bug. Is it?\n>\n> a reference that is named \"@\" only is invalid, but refs/tags/@ is not.\n\n;-) \n\n\"git check-ref-format master ; echo $?\" would show that any single\nlevel name is \"forbidden\", so probably the SO commenter (whatever\nthat is) was confused---it is not about @ at all.\n\nIn any case, a tag whose name is @ may be another source of\nconfusion in the modern world, after we added @ as a synonym to\nHEAD. I do not know, for example, offhand which between the HEAD or\nthat tag \"git show @\" would choose. It makes sense to avoid it.\n"},{"id":"436270","messageId":"YUUM5VqTEtjhnfjj@coredump.intra.peff.net","threadId":"56522","inReplyTo":"xmqq4kaihqjj.fsf@gitster.g","subject":"Re: Should `@` be really a valid git tag name?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-09-17T21:47:17Z","receivedAt":"2021-09-17T21:47:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 17, 2021 at 01:53:52PM -0700, Junio C Hamano wrote:\n\n> Carlo Arenas writes:\n> \n> > On Fri, Sep 17, 2021 at 7:12 AM wrote:\n> >>\n> >> A SO commenter pointed out, that git-check-ref-format forbids @ and\n> >> maybe I should report this as a potential bug. Is it?\n> >\n> > a reference that is named \"@\" only is invalid, but refs/tags/@ is not.\n> \n> ;-) \n> \n> \"git check-ref-format master ; echo $?\" would show that any single\n> level name is \"forbidden\", so probably the SO commenter (whatever\n> that is) was confused---it is not about @ at all.\n> \n> In any case, a tag whose name is @ may be another source of\n> confusion in the modern world, after we added @ as a synonym to\n> HEAD. I do not know, for example, offhand which between the HEAD or\n> that tag \"git show @\" would choose. It makes sense to avoid it.\n\nIn the past when we've had confusing names (like refs/heads/HEAD), we\ncontinue to allow them at the plumbing level (to retain backwards\ncompatibility), but flag them at the porcelain level to prevent users\nshooting themselves in the foot. This seems like a good candidate for\nthat (for both git-branch and git-tag).\n\n-Peff\n"},{"id":"436281","messageId":"YUUdjNDkL7Uy5erG@carlos-mbp.lan","threadId":"56522","inReplyTo":"YUUM5VqTEtjhnfjj@coredump.intra.peff.net","subject":"Re: Should `@` be really a valid git tag name?","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2021-09-17T22:58:20Z","receivedAt":"2021-09-17T22:58:25Z","isPatch":false,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Fri, Sep 17, 2021 at 05:47:17PM -0400, Jeff King wrote:\n> On Fri, Sep 17, 2021 at 01:53:52PM -0700, Junio C Hamano wrote:\n> > > On Fri, Sep 17, 2021 at 7:12 AM wrote:\n> > >>\n> > >> A SO commenter pointed out, that git-check-ref-format forbids @ and\n> > >> maybe I should report this as a potential bug. Is it?\n> > >\n> > > a reference that is named \"@\" only is invalid, but refs/tags/@ is not.\n> > \n> > ;-) \n> > \n> > \"git check-ref-format master ; echo $?\" would show that any single\n> > level name is \"forbidden\", so probably the SO commenter (whatever\n> > that is) was confused---it is not about @ at all.\n> > \n> > In any case, a tag whose name is @ may be another source of\n> > confusion in the modern world, after we added @ as a synonym to\n> > HEAD. I do not know, for example, offhand which between the HEAD or\n> > that tag \"git show @\" would choose. It makes sense to avoid it.\n> \n> In the past when we've had confusing names (like refs/heads/HEAD), we\n> continue to allow them at the plumbing level (to retain backwards\n> compatibility), but flag them at the porcelain level to prevent users\n> shooting themselves in the foot. This seems like a good candidate for\n> that (for both git-branch and git-tag).\n\nI was leaning towards something like that plus a Documentation update, but\nnoticed that the current behaviour was inconsistent, and the confusion\npointed out by Junio seems to indicate it is better if fully restricted.\n\nCarlo\n\n----- >8 -----\nSubject: [PATCH] refs: mark \"@\" as an invalid refspec\n\n9ba89f484e (Add new @ shortcut for HEAD, 2013-09-02), adds \"@\" to\nthe list of invalid refspec, but does it only for full refspec and\nnot as a component.\n\nMove the logic to validate it at the component level to prevent also\ntags to be created with that name.\n\nReported-by: Benjamin \nSigned-off-by: Carlo Marcelo Arenas Belón \n---\n refs.c | 19 ++++++++++---------\n 1 file changed, 10 insertions(+), 9 deletions(-)\n\ndiff --git a/refs.c b/refs.c\nindex 8b9f7c3a80..2ca6995c0f 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -47,13 +47,14 @@ int ref_storage_backend_exists(const char *name)\n * 4: A bad character: ASCII control characters, and\n * \":\", \"?\", \"[\", \"\\\", \"^\", \"~\", SP, or TAB\n * 5: *, reject unless REFNAME_REFSPEC_PATTERN is set\n+ * 6: @, only valid if used around valid characters\n */\n static unsigned char refname_disposition[256] = {\n \t1, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,\n \t4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,\n \t4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 2, 1,\n \t0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 4,\n-\t0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,\n+\t6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,\n \t0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 4, 0, 4, 0,\n \t0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,\n \t0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 4, 4\n@@ -137,6 +138,14 @@ static int check_refname_component(const char *refname, int *flags,\n \t\t\t */\n \t\t\t*flags &= ~ REFNAME_REFSPEC_PATTERN;\n \t\t\tbreak;\n+\t\tcase 6:\n+\t\t\tif (last == '\\0' && *(cp + 1) == '\\0') {\n+\t\t\t\tif (sanitized)\n+\t\t\t\t\tsanitized->buf[sanitized->len] = '-';\n+\t\t\t\telse\n+\t\t\t\t\treturn -1;\n+\t\t\t}\n+\t\t\tbreak;\n \t\t}\n \t\tlast = ch;\n \t}\n@@ -167,14 +176,6 @@ static int check_or_sanitize_refname(const char *refname, int flags,\n {\n \tint component_len, component_count = 0;\n \n-\tif (!strcmp(refname, \"@\")) {\n-\t\t/* Refname is a single character '@'. */\n-\t\tif (sanitized)\n-\t\t\tstrbuf_addch(sanitized, '-');\n-\t\telse\n-\t\t\treturn -1;\n-\t}\n-\n \twhile (1) {\n \t\tif (sanitized && sanitized->len)\n \t\t\tstrbuf_complete(sanitized, '/');\n-- \n2.33.0.911.gbe391d4e11\n"},{"id":"436283","messageId":"xmqqr1dmg5uq.fsf@gitster.g","threadId":"56522","inReplyTo":"YUUdjNDkL7Uy5erG@carlos-mbp.lan","subject":"Re: Should `@` be really a valid git tag name?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-09-17T23:06:05Z","receivedAt":"2021-09-17T23:06:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlo Marcelo Arenas Belón writes:\n\n> I was leaning towards something like that plus a Documentation update, but\n> noticed that the current behaviour was inconsistent, and the confusion\n> pointed out by Junio seems to indicate it is better if fully restricted.\n\nThat is a bad move, as existing repositories may have a ref with\nsuch a name.\n\nIf we tighten anything retroactively, we probably should forgid '@'\nshort-hand that stands for HEAD, I would think.\n"},{"id":"436286","messageId":"CAPUEspg3982Wk7vdO-vFimvyApzYwUtsryZdLt1=sLfrrYngyg@mail.gmail.com","threadId":"56522","inReplyTo":"xmqqr1dmg5uq.fsf@gitster.g","subject":"Re: Should `@` be really a valid git tag name?","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2021-09-18T00:21:49Z","receivedAt":"2021-09-18T00:22:05Z","isPatch":false,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Fri, Sep 17, 2021 at 4:06 PM Junio C Hamano wrote:\n>\n> Carlo Marcelo Arenas Belón writes:\n>\n> > I was leaning towards something like that plus a Documentation update, but\n> > noticed that the current behaviour was inconsistent, and the confusion\n> > pointed out by Junio seems to indicate it is better if fully restricted.\n>\n> That is a bad move, as existing repositories may have a ref with\n> such a name.\n\nbut if they do, it is currently \"ambiguous\" as you pointed out, and my\npatch still allows the use of @ when it is not ambiguous :\n\n $ git branch @/1 @\n\nso Stefano[1] is safe, and anyone that has such a ref is better of\nrenaming it anyway (which is something I agree we have to add code to\nmy patch to allow somehow)\n\n> If we tighten anything retroactively, we probably should forgid '@'\n> short-hand that stands for HEAD, I would think.\n\nregardless of the merits of that feature, it has been in git since\n~v1.8.4, so its removal will also be breaking the user experience\nIMHO.\n\nCarlo\n\n[1] https://lore.kernel.org/git/520BC017.7050907@gmail.com/\n"},{"id":"436287","messageId":"xmqqh7eig25r.fsf@gitster.g","threadId":"56522","inReplyTo":"CAPUEspg3982Wk7vdO-vFimvyApzYwUtsryZdLt1=sLfrrYngyg@mail.gmail.com","subject":"Re: Should `@` be really a valid git tag name?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-09-18T00:25:52Z","receivedAt":"2021-09-18T00:25:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlo Arenas writes:\n\n> On Fri, Sep 17, 2021 at 4:06 PM Junio C Hamano wrote:\n>>\n>> Carlo Marcelo Arenas Belón writes:\n>>\n>> > I was leaning towards something like that plus a Documentation update, but\n>> > noticed that the current behaviour was inconsistent, and the confusion\n>> > pointed out by Junio seems to indicate it is better if fully restricted.\n>>\n>> That is a bad move, as existing repositories may have a ref with\n>> such a name.\n> ...\n>> If we tighten anything retroactively, we probably should forgid '@'\n>> short-hand that stands for HEAD, I would think.\n>\n> regardless of the merits of that feature, it has been in git since\n> ~v1.8.4, so its removal will also be breaking the user experience\n> IMHO.\n\nI know, but it is lessor of two evils.\n\nI think it is OK to forbid at the higher level Porcelain, while\nstill allowing read access, but keep the door open for plumbing,\njust like Peff suggested.\n"},{"id":"436293","messageId":"YUVwvw+T3C/QXQ52@carlos-mbp.lan","threadId":"56522","inReplyTo":"xmqqh7eig25r.fsf@gitster.g","subject":"Re: Should `@` be really a valid git tag name?","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2021-09-18T04:53:19Z","receivedAt":"2021-09-18T04:53:24Z","isPatch":false,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Fri, Sep 17, 2021 at 05:25:52PM -0700, Junio C Hamano wrote:\n> \n> I think it is OK to forbid at the higher level Porcelain, while\n> still allowing read access, but keep the door open for plumbing,\n> just like Peff suggested.\n\nI still think it would be better to forbid it fully (at least longterm)\nand while I am not advocating for (neither against) the feature that\nrequired a character to be reserved, I think it is good to have a way\nto reserve more characters if needed, and so this might help as a POC.\n\nThe patch could use a better message, and covers all porcelain points\nI am aware of (branch, tag, checkout and switch), but leaves push/pull\nintentionally open.\n\nI think preventing push might be worth adding, but I am concerned it\nmight be too intrusive; I coded a warning for tag, but I frankly suspect\nno one really HAS a tag like this that they really want to keep, and the\nreported problem behaves better with the new code (local/remote tag can\nbe removed normally):\n\n $ git log --oneline\n 813e919 (HEAD -> master, tag: a, tag: @@, tag: @1, tag: 1@, origin/master, @) HEAD\n d52caf3 (tag: z, tag: foo, tag: bar, tag: @) init\n $ git tag -d @\n Deleted tag '@' (was d52caf3)\n $ git push origin :@\n To origin\n - [deleted] @\n\nCarlo\n----- >8 -----\nSubject: [RFC PATCH] refs: mark \"@\" as an invalid refname in the porcelain\n\n9ba89f484e (Add new @ shortcut for HEAD, 2013-09-02) declares \"@\"\nas an invalid refname, but only blocked it as a full refname and\nnot when a component of one, leaving a loophole that was tested\nin t3204.11, even if ambiguous.\n\nRemove the check and instead add it at the porcelain level, so\nusers will be blocked of creating tags or branches named \"@\", but\nstill allowed to delete or rename them in a consistent way.\n\nTo help transition, add a warning if \"@\" is used as a branch, so\nthat check could be removed and implemente properly in the future.\n\nSigned-off-by: Carlo Marcelo Arenas Belón \n---\n branch.c | 7 +++++++\n builtin/branch.c | 3 +++\n builtin/checkout.c | 5 ++++-\n builtin/tag.c | 3 +++\n refs.c | 8 --------\n t/t3204-branch-name-interpretation.sh | 8 ++++----\n 6 files changed, 21 insertions(+), 13 deletions(-)\n\ndiff --git a/branch.c b/branch.c\nindex 7a88a4861e..a577a3ddc1 100644\n--- a/branch.c\n+++ b/branch.c\n@@ -185,6 +185,13 @@ int read_branch_desc(struct strbuf *buf, const char *branch_name)\n */\n int validate_branchname(const char *name, struct strbuf *ref)\n {\n+\t/*\n+\t * since 9ba89f484e (Add new @ shortcut for HEAD, 2013-09-02)\n+\t * \"@\" is no longer a valid reference.\n+\t */\n+\tif (!strcmp(name, \"@\"))\n+\t\tdie(_(\"'@' is an ambiguous refname\"));\n+\n \tif (strbuf_check_branch_ref(ref, name))\n \t\tdie(_(\"'%s' is not a valid branch name.\"), name);\n \ndiff --git a/builtin/branch.c b/builtin/branch.c\nindex b23b1d1752..7a5a10ad82 100644\n--- a/builtin/branch.c\n+++ b/builtin/branch.c\n@@ -857,6 +857,9 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\tif (track == BRANCH_TRACK_OVERRIDE)\n \t\t\tdie(_(\"the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead.\"));\n \n+\t\tif (!strcmp(argv[0], \"@\"))\n+\t\t\tdie(_(\"'@' is ambiguous\"));\n+\n \t\tcreate_branch(the_repository,\n \t\t\t argv[0], (argc == 2) ? argv[1] : head,\n \t\t\t force, 0, reflog, quiet, track);\ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex b5d477919a..bc92a2c723 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -1151,8 +1151,11 @@ static void setup_new_branch_info_and_source_tree(\n \tsetup_branch_path(new_branch_info);\n \n \tif (!check_refname_format(new_branch_info->path, 0) &&\n-\t !read_ref(new_branch_info->path, &branch_rev))\n+\t !read_ref(new_branch_info->path, &branch_rev)) {\n \t\toidcpy(rev, &branch_rev);\n+\t\tif (!strcmp(new_branch_info->name, \"@\"))\n+\t\t\twarning(\"ambiguous name, rename this branch ASAP\");\n+\t}\n \telse {\n \t\tfree((char *)new_branch_info->path);\n \t\tnew_branch_info->path = NULL; /* not an existing branch */\ndiff --git a/builtin/tag.c b/builtin/tag.c\nindex 82fcfc0982..357efc37f8 100644\n--- a/builtin/tag.c\n+++ b/builtin/tag.c\n@@ -608,6 +608,9 @@ int cmd_tag(int argc, const char **argv, const char *prefix)\n \telse\n \t\tdie(_(\"Invalid cleanup mode %s\"), cleanup_arg);\n \n+\tif (!strcmp(tag, \"@\"))\n+\t\tdie(_(\"'@' is ambiguous\"));\n+\n \tcreate_reflog_msg(&object, &reflog_msg);\n \n \tif (create_tag_object) {\ndiff --git a/refs.c b/refs.c\nindex 8b9f7c3a80..6b5d869bf5 100644\n--- a/refs.c\n+++ b/refs.c\n@@ -167,14 +167,6 @@ static int check_or_sanitize_refname(const char *refname, int flags,\n {\n \tint component_len, component_count = 0;\n \n-\tif (!strcmp(refname, \"@\")) {\n-\t\t/* Refname is a single character '@'. */\n-\t\tif (sanitized)\n-\t\t\tstrbuf_addch(sanitized, '-');\n-\t\telse\n-\t\t\treturn -1;\n-\t}\n-\n \twhile (1) {\n \t\tif (sanitized && sanitized->len)\n \t\t\tstrbuf_complete(sanitized, '/');\ndiff --git a/t/t3204-branch-name-interpretation.sh b/t/t3204-branch-name-interpretation.sh\nindex 993a6b5eff..862a5dff8e 100755\n--- a/t/t3204-branch-name-interpretation.sh\n+++ b/t/t3204-branch-name-interpretation.sh\n@@ -110,11 +110,11 @@ test_expect_success 'disallow deleting remote branch via @{-1}' '\n \n # The thing we are testing here is that \"@\" is the real branch refs/heads/@,\n # and not refs/heads/HEAD. These tests should not imply that refs/heads/@ is a\n-# sane thing, but it _is_ technically allowed for now. If we disallow it, these\n-# can be switched to test_must_fail.\n+# sane thing, and should go away once \"@\" is correctly marked as an invalid\n+# refname\n test_expect_success 'create branch named \"@\"' '\n-\tgit branch -f @ one &&\n-\texpect_branch refs/heads/@ one\n+\ttest_must_fail git branch -f @ one 2>err &&\n+\tgrep \"fatal: '\\''@'\\'' is ambiguous\" err\n '\n \n test_expect_success 'delete branch named \"@\"' '\n-- \n2.33.0.911.gbe391d4e11\n\n"},{"id":"436304","messageId":"CAPx1GvdL4gNQhLwaF0useXXWzXXFRxZekuFEcSkyOOTniueFTg@mail.gmail.com","threadId":"56522","inReplyTo":"xmqq4kaihqjj.fsf@gitster.g","subject":"Re: Should `@` be really a valid git tag name?","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2021-09-18T13:45:05Z","receivedAt":"2021-09-18T13:45:20Z","isPatch":false,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"I was in fact the commenter, and I wasn't saying\nthat it is a bug in check-ref-format, but rather that\nsince `@` by itself is forbidden, perhaps the creation\nof a tag or branch named `@` should be forbidden.\nMaybe it should even be forbidden as any component\npart, in new names, although obviously we would\nhave to allow deleting existing names!\n\nI knew this would be a bit of a hornet's nest though,\n\nChris\n\nOn Fri, Sep 17, 2021 at 9:37 PM Junio C Hamano wrote:\n>\n> Carlo Arenas writes:\n>\n> > On Fri, Sep 17, 2021 at 7:12 AM wrote:\n> >>\n> >> A SO commenter pointed out, that git-check-ref-format forbids @ and\n> >> maybe I should report this as a potential bug. Is it?\n> >\n> > a reference that is named \"@\" only is invalid, but refs/tags/@ is not.\n>\n> ;-)\n>\n> \"git check-ref-format master ; echo $?\" would show that any single\n> level name is \"forbidden\", so probably the SO commenter (whatever\n> that is) was confused---it is not about @ at all.\n>\n> In any case, a tag whose name is @ may be another source of\n> confusion in the modern world, after we added @ as a synonym to\n> HEAD. I do not know, for example, offhand which between the HEAD or\n> that tag \"git show @\" would choose. It makes sense to avoid it.\n"}]}