On Thu, Nov 28, 2024 at 08:30:10AM +0900, Junio C Hamano wrote:
> 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.
> - 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.
> 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
