summaryrefslogtreecommitdiff
path: root/ls-refs.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2019-05-23 06:11:21 (GMT)
committerJunio C Hamano <gitster@pobox.com>2019-05-28 17:02:00 (GMT)
commit533e088250cf4e8aad3143586850d7a89ed30571 (patch)
treecb59ea02d4926699c4e42aced5f81423c8b2a0f1 /ls-refs.c
parentaeb582a98374c094361cba1bd756dc6307432c42 (diff)
downloadgit-533e088250cf4e8aad3143586850d7a89ed30571.zip
git-533e088250cf4e8aad3143586850d7a89ed30571.tar.gz
git-533e088250cf4e8aad3143586850d7a89ed30571.tar.bz2
upload-pack: strip namespace from symref data
Since 7171d8c15f (upload-pack: send symbolic ref information as capability, 2013-09-17), we've sent cloning and fetching clients special information about which branch HEAD is pointing to, so that they don't have to guess based on matching up commit ids. However, this feature has never worked properly with the GIT_NAMESPACE feature. Because upload-pack uses head_ref_namespaced(find_symref), we do find and report on refs/namespaces/foo/HEAD instead of the actual HEAD of the repo. This makes sense, since the branch pointed to by the top-level HEAD may not be advertised at all. But we do two things wrong: 1. We report the full name refs/namespaces/foo/HEAD, instead of just HEAD. Meaning no client is going to bother doing anything with that symref, since we're not otherwise advertising it. 2. We report the symref destination using its full name (e.g., refs/namespaces/foo/refs/heads/master). That's similarly useless to the client, who only saw "refs/heads/master" in the advertisement. We should be stripping the namespace prefix off of both places (which this patch fixes). Likely nobody noticed because we tend to do the right thing anyway. Bug (1) means that we said nothing about HEAD (just refs/namespace/foo/HEAD). And so the client half of the code, from a45b5f0552 (connect: annotate refs with their symref information in get_remote_head(), 2013-09-17), does not annotate HEAD, and we use the fallback in guess_remote_head(), matching refs by object id. Which is usually right. It only falls down in ambiguous cases, like the one laid out in the included test. This also means that we don't have to worry about breaking anybody who was putting pre-stripped names into their namespace symrefs when we fix bug (2). Because of bug (1), nobody would have been using the symref we advertised in the first place (not to mention that those symrefs would have appeared broken for any non-namespaced access). Note that we have separate fixes here for the v0 and v2 protocols. The symref advertisement moved in v2 to be a part of the ls-refs command. This actually gets part (1) right, since the symref annotation piggy-backs on the existing ref advertisement, which is properly stripped. But it still needs a fix for part (2). The included tests cover both protocols. Reported-by: Bryan Turner <bturner@atlassian.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'ls-refs.c')
-rw-r--r--ls-refs.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/ls-refs.c b/ls-refs.c
index 0a7dbc6..818aef7 100644
--- a/ls-refs.c
+++ b/ls-refs.c
@@ -57,7 +57,8 @@ static int send_ref(const char *refname, const struct object_id *oid,
if (!symref_target)
die("'%s' is a symref but it is not?", refname);
- strbuf_addf(&refline, " symref-target:%s", symref_target);
+ strbuf_addf(&refline, " symref-target:%s",
+ strip_namespace(symref_target));
}
if (data->peel) {