{"thread":{"id":"62550","subject":"git tag -a HEAD leads to ambiguous branch name","startedAt":"2024-11-27T00:14:33Z","lastAt":"2024-12-02T04:38:23Z","messageCount":5,"participants":["git@jowil.de","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"508201","messageId":"47cdf937-6192-4c83-a0e5-700e98f36c1e@jowil.de","threadId":"62550","inReplyTo":null,"subject":"git tag -a HEAD leads to ambiguous branch name","fromName":"","fromEmail":"git@jowil.de","sentAt":"2024-11-27T00:14:23Z","receivedAt":"2024-11-27T00:14:33Z","isPatch":false,"sender":{"key":"git@jowil.de","avatar":null},"body":"Good evening,\ntoday I encountered a warning using  git version 2.39.0.windows.2:\n/warning: refname 'HEAD' is ambiguous./\nIt turned out, having written\n/git tag -a HEAD -m \"Some message.\"/\nwas the culprit.\nAs\n/git branch HEAD/\nyields the following error\n/fatal: 'HEAD' is not a valid branch name/\nI wanted to aks, whether a similar check should  be applied to tag names.\nBest regards\nJohannes Wilde\n\n"},{"id":"508230","messageId":"20241127142711.GB1712@coredump.intra.peff.net","threadId":"62550","inReplyTo":"47cdf937-6192-4c83-a0e5-700e98f36c1e@jowil.de","subject":"Re: git tag -a HEAD leads to ambiguous branch name","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-11-27T14:27:11Z","receivedAt":"2024-11-27T14:27:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 27, 2024 at 01:14:23AM +0100, git@jowil.de wrote:\n\n> today I encountered a warning using  git version 2.39.0.windows.2:\n> /warning: refname 'HEAD' is ambiguous./\n> It turned out, having written\n> /git tag -a HEAD -m \"Some message.\"/\n> was the culprit.\n> As\n> /git branch HEAD/\n> yields the following error\n> /fatal: 'HEAD' is not a valid branch name/\n> I wanted to aks, whether a similar check should  be applied to tag names.\n\nYes, I think that's reasonable. We won't ever completely forbid \"HEAD\"\nas a branch or tag name for historical reasons. But when porcelain like\ngit-branch or git-tag sees it, it is almost certainly a typo or\nforgotten argument.\n\n-Peff\n"},{"id":"508247","messageId":"xmqqh67ss1a5.fsf@gitster.g","threadId":"62550","inReplyTo":"20241127142711.GB1712@coredump.intra.peff.net","subject":"Re: git tag -a HEAD leads to ambiguous branch name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-11-27T23:30:10Z","receivedAt":"2024-11-27T23:30:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Yes, I think that's reasonable. We won't ever completely forbid \"HEAD\"\n> as a branch or tag name for historical reasons. But when porcelain like\n> git-branch or git-tag sees it, it is almost certainly a typo or\n> forgotten argument.\n\nA quick band-aid would be\n\n builtin/tag.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git c/builtin/tag.c w/builtin/tag.c\nindex 93d10d5915..c91aba5e26 100644\n--- c/builtin/tag.c\n+++ w/builtin/tag.c\n@@ -449,7 +449,7 @@ static int parse_msg_arg(const struct option *opt, const char *arg, int unset)\n \n static int strbuf_check_tag_ref(struct strbuf *sb, const char *name)\n {\n-\tif (name[0] == '-')\n+\tif (name[0] == '-' || !strcmp(name, \"HEAD\"))\n \t\treturn -1;\n \n \tstrbuf_reset(sb);\n\nbut this (together with what \"git branch\" uses) is unsatisfactory\nfor at least two reasons.\n\n - This helper function and object-name.c:strbuf_check_branch_ref()\n   should not be named with \"strbuf_\" prefix.  \n\n - The right place to do these checks is check_refname_format(), but\n   it would retroactively forbid porcelains from using HEAD as the\n   name of a branch or a tag (which is technically allowed, but it\n   is dubious anybody wants to do so because it is so cumbersome to\n   use).\n\nThere is a dubious test in t5604 that expects you can create such a\ntag.  t5604.22 wants to create one:\n\ntest_expect_success 'clone with reference from a tagged repository' '\n\t(\n\t\tcd A && git tag -a -m tagged HEAD\n\t) &&\n\tgit clone --reference=A A I\n'\n\nand t5604.24 wants to use it.\n\ntest_expect_success 'fetch with incomplete alternates' '\n\tgit init K &&\n\techo \"$base_dir/A/.git/objects\" >K/.git/objects/info/alternates &&\n\t(\n\t\tcd K &&\n\t\tgit remote add J \"file://$base_dir/J\" &&\n\t\tGIT_TRACE_PACKET=$U.K git fetch J\n\t) &&\n\tmain_object=$(cd A && git for-each-ref --format=\"%(objectname)\" refs/heads/main) &&\n\ttest -s \"$U.K\" &&\n\t! grep \" want $main_object\" \"$U.K\" &&\n\ttag_object=$(cd A && git for-each-ref --format=\"%(objectname)\" refs/tags/HEAD) &&\n\t! grep \" want $tag_object\" \"$U.K\"\n'\n\nIf we did this check at check_refname_format() level, it probably\nwill affect cloning from an existing repository with such a branch\nor a tag.\n"},{"id":"508401","messageId":"20241201224408.GJ145938@coredump.intra.peff.net","threadId":"62550","inReplyTo":"xmqqh67ss1a5.fsf@gitster.g","subject":"Re: git tag -a HEAD leads to ambiguous branch name","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-12-01T22:44:08Z","receivedAt":"2024-12-01T22:44:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 28, 2024 at 08:30:10AM +0900, Junio C Hamano wrote:\n\n> diff --git c/builtin/tag.c w/builtin/tag.c\n> index 93d10d5915..c91aba5e26 100644\n> --- c/builtin/tag.c\n> +++ w/builtin/tag.c\n> @@ -449,7 +449,7 @@ static int parse_msg_arg(const struct option *opt, const char *arg, int unset)\n>  \n>  static int strbuf_check_tag_ref(struct strbuf *sb, const char *name)\n>  {\n> -\tif (name[0] == '-')\n> +\tif (name[0] == '-' || !strcmp(name, \"HEAD\"))\n>  \t\treturn -1;\n>  \n>  \tstrbuf_reset(sb);\n> \n> but this (together with what \"git branch\" uses) is unsatisfactory\n> for at least two reasons.\n> \n>  - This helper function and object-name.c:strbuf_check_branch_ref()\n>    should not be named with \"strbuf_\" prefix. \n\nAgreed here.\n\n>  - The right place to do these checks is check_refname_format(), but\n>    it would retroactively forbid porcelains from using HEAD as the\n>    name of a branch or a tag (which is technically allowed, but it\n>    is dubious anybody wants to do so because it is so cumbersome to\n>    use).\n\nBut I don't know about this. I thought when we outlawed \"git branch\nHEAD\" that it was quite intentional _not_ to forbid these names at the\nlowest level in order to retain backwards compatibility. They are just\nabout preventing common UI mistakes.\n\nI'm OK with revisiting that decision, but:\n\n  1. I think it's orthogonal to adding a similar UI-level check for\n     git-tag.\n\n  2. We'd probably need some deprecation period or breaking-changes\n     moment to do the switch.\n\n> There is a dubious test in t5604 that expects you can create such a\n> tag.  t5604.22 wants to create one:\n> \n> test_expect_success 'clone with reference from a tagged repository' '\n> \t(\n> \t\tcd A && git tag -a -m tagged HEAD\n> \t) &&\n> \tgit clone --reference=A A I\n> '\n> \n> and t5604.24 wants to use it.\n\nWeird. Comes from 09116a1c31 (refs: loosen over-strict \"format\" check,\n2011-11-16). I don't see any reason it could not just be \"foo\".\n\n-Peff\n"},{"id":"508411","messageId":"xmqqwmgiits3.fsf@gitster.g","threadId":"62550","inReplyTo":"20241201224408.GJ145938@coredump.intra.peff.net","subject":"Re: git tag -a HEAD leads to ambiguous branch name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-12-02T04:38:20Z","receivedAt":"2024-12-02T04:38:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> But I don't know about this. I thought when we outlawed \"git branch\n> HEAD\" that it was quite intentional _not_ to forbid these names at the\n> lowest level in order to retain backwards compatibility. They are just\n> about preventing common UI mistakes.\n\nYeah, I think this is a sensible way to think about it.\n\n>> There is a dubious test in t5604 that expects you can create such a\n>> tag.  t5604.22 wants to create one:\n>> \n>> test_expect_success 'clone with reference from a tagged repository' '\n>> \t(\n>> \t\tcd A && git tag -a -m tagged HEAD\n>> \t) &&\n>> \tgit clone --reference=A A I\n>> '\n>> \n>> and t5604.24 wants to use it.\n>\n> Weird. Comes from 09116a1c31 (refs: loosen over-strict \"format\" check,\n> 2011-11-16). I don't see any reason it could not just be \"foo\".\n\nHmph, yeah, reverting the code change of 09116a1c31 and then using\n'foo' instead of 'HEAD' fails the test exactly the same way.\n"}]}