From: Bryan Turner <firstname.lastname@example.org> To: Git Users <email@example.com> Subject: HEAD and namespaces Date: Mon, 20 May 2019 19:59:03 -0700 [thread overview] Message-ID: <CAGyf7-Ew8rS8n67Few9+dT6VXy9rQbaYLswuZkQ3-4j_T_dfirstname.lastname@example.org> (raw) When using GIT_NAMESPACE, it appears the "symref" added to the capabilities advertisement doesn't get the namespace stripped. The namespace is stripped for the advertised refs, including "HEAD", but not on the "symref". Lafiel:test bturner$ GIT_NAMESPACE=foo GIT_TRACE_PACKET=1 git ls-remote origin 19:51:54.012696 pkt-line.c:80 packet: git< b9acca03606d4c674be8b7e79cd788cedbec957c HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed symref=refs/namespaces/foo/HEAD:refs/namespaces/foo/refs/heads/master agent=git/2.20.1 19:51:54.013017 pkt-line.c:80 packet: git< b9acca03606d4c674be8b7e79cd788cedbec957c refs/heads/master 19:51:54.013028 pkt-line.c:80 packet: git< 0000 19:51:54.013035 pkt-line.c:80 packet: git> 0000 b9acca03606d4c674be8b7e79cd788cedbec957c HEAD b9acca03606d4c674be8b7e79cd788cedbec957c refs/heads/master I don't know whether the client somehow does some stripping on the "symref" to decide that HEAD should be "refs/namespaces/foo/refs/heads/master", but I'd assume not. Either way, since the clone can't find the HEAD value (either because it doesn't see "refs/namespaces/foo/HEAD" as HEAD, which I'd assume is the case, or because it can't find "refs/namespaces/foo/refs/heads/master"), it falls back on the old behavior of picking the first branch with a matching commit. That brings back all the "wrong branch" issues with cloning that adding "symref" fixed. Is this a bug? An oversight? An intentional decision? How is HEAD supposed to work when using GIT_NAMESPACE? Perhaps the expectation is that namespaces won't have their own HEADs? I'd say perhaps it's that even in the namespace the target ref shouldn't be namespaced, but that doesn't seem like it could possibly be correct since the namespace could contain refs that don't exist outside it, so Git would see the symbolic ref as broken. Any insight would be greatly appreciated! Bryan
next reply other threads:[~2019-05-21 2:59 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-21 2:59 Bryan Turner [this message] 2019-05-21 21:46 ` Jeff King 2019-05-22 4:31 ` [PATCH] upload-pack: strip namespace from symref data Jeff King 2019-05-22 10:33 ` Ævar Arnfjörð Bjarmason 2019-05-23 6:11 ` [PATCH v2] " Jeff King 2019-05-28 17:01 ` 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 List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAGyf7-Ew8rS8n67Few9+dT6VXy9rQbaYLswuZkQ3-4j_T_demail@example.com' \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: HEAD and namespaces' \ /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
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).