Re: git tag -a HEAD leads to ambiguous branch name
- From
Jeff King <peff@peff.net>
- Date
- Dec 1, 2024, 22:44 UTC
- Message-ID
- <20241201224408.GJ145938@coredump.intra.peff.net>
- In-Reply-To
- <xmqqh67ss1a5.fsf@gitster.g>
On Thu, Nov 28, 2024 at 08:30:10AM +0900, Junio C Hamano wrote:
Show 19 quoted lines
> diff --git c/builtin/tag.c w/builtin/tag.c
> index 93d10d5915..c91aba5e26 100644
> --- c/builtin/tag.c
> +++ w/builtin/tag.c
> @@ -449,7 +449,7 @@ static int parse_msg_arg(const struct option *opt, const char *arg, int unset)
>
> static int strbuf_check_tag_ref(struct strbuf *sb, const char *name)
> {
> - if (name[0] == '-')
> + if (name[0] == '-' || !strcmp(name, "HEAD"))
> return -1;
>
> strbuf_reset(sb);
>
> but this (together with what "git branch" uses) is unsatisfactory
> for at least two reasons.
>
> - This helper function and object-name.c:strbuf_check_branch_ref()
> should not be named with "strbuf_" prefix. Agreed here.
Show 5 quoted lines
> - The right place to do these checks is check_refname_format(), but > it would retroactively forbid porcelains from using HEAD as the > name of a branch or a tag (which is technically allowed, but it > is dubious anybody wants to do so because it is so cumbersome to > use).
But I don't know about this. I thought when we outlawed "git branch HEAD" that it was quite intentional _not_ to forbid these names at the lowest level in order to retain backwards compatibility. They are just about preventing common UI mistakes.
I'm OK with revisiting that decision, but:
1. I think it's orthogonal to adding a similar UI-level check for
git-tag. 2. We'd probably need some deprecation period or breaking-changes
moment to do the switch.Show 11 quoted lines
> There is a dubious test in t5604 that expects you can create such a > tag. t5604.22 wants to create one: > > test_expect_success 'clone with reference from a tagged repository' ' > ( > cd A && git tag -a -m tagged HEAD > ) && > git clone --reference=A A I > ' > > and t5604.24 wants to use it.
Weird. Comes from 09116a1c31 (refs: loosen over-strict "format" check, 2011-11-16). I don't see any reason it could not just be "foo".
-Peff