From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@jowil.de, git@vger.kernel.org
Subject: Re: git tag -a HEAD leads to ambiguous branch name
Date: Thu, 28 Nov 2024 08:30:10 +0900 [thread overview]
Message-ID: <xmqqh67ss1a5.fsf@gitster.g> (raw)
In-Reply-To: <20241127142711.GB1712@coredump.intra.peff.net> (Jeff King's message of "Wed, 27 Nov 2024 09:27:11 -0500")
Jeff King <peff@peff.net> writes:
> Yes, I think that's reasonable. We won't ever completely forbid "HEAD"
> as a branch or tag name for historical reasons. But when porcelain like
> git-branch or git-tag sees it, it is almost certainly a typo or
> forgotten argument.
A quick band-aid would be
builtin/tag.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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.
- 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).
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.
test_expect_success 'fetch with incomplete alternates' '
git init K &&
echo "$base_dir/A/.git/objects" >K/.git/objects/info/alternates &&
(
cd K &&
git remote add J "file://$base_dir/J" &&
GIT_TRACE_PACKET=$U.K git fetch J
) &&
main_object=$(cd A && git for-each-ref --format="%(objectname)" refs/heads/main) &&
test -s "$U.K" &&
! grep " want $main_object" "$U.K" &&
tag_object=$(cd A && git for-each-ref --format="%(objectname)" refs/tags/HEAD) &&
! grep " want $tag_object" "$U.K"
'
If we did this check at check_refname_format() level, it probably
will affect cloning from an existing repository with such a branch
or a tag.
next prev parent reply other threads:[~2024-11-27 23:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-27 0:14 git tag -a HEAD leads to ambiguous branch name git
2024-11-27 14:27 ` Jeff King
2024-11-27 23:30 ` Junio C Hamano [this message]
2024-12-01 22:44 ` Jeff King
2024-12-02 4:38 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqh67ss1a5.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@jowil.de \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.