mirror of
https://github.com/git/git.git
synced 2024-12-13 03:44:17 +08:00
ls-remote: do not send ref prefixes for patterns
Since b4be74105f
(ls-remote: pass ref prefixes when requesting a
remote's refs, 2018-03-15), "ls-remote foo" will pass "refs/heads/foo",
"refs/tags/foo", etc to the transport code in an attempt to let the
other side reduce the size of its advertisement.
Unfortunately this is not correct, as ls-remote patterns do not follow
the usual ref lookup rules, and are in fact tail-matched. So we could
find "refs/heads/foo" or "refs/heads/a/much/deeper/foo" or even
"refs/another/hierarchy/foo".
Since we can't pass a prefix and there's not yet a v2 extension for
matching wildcards, we must disable this feature to keep the same
behavior as v1.
Reported-by: Jon Simons <jon@jonsimons.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
parent
268fbcd172
commit
631f0f8c4b
@ -88,15 +88,7 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
|
||||
int i;
|
||||
pattern = xcalloc(argc, sizeof(const char *));
|
||||
for (i = 1; i < argc; i++) {
|
||||
const char *glob;
|
||||
pattern[i - 1] = xstrfmt("*/%s", argv[i]);
|
||||
|
||||
glob = strchr(argv[i], '*');
|
||||
if (glob)
|
||||
argv_array_pushf(&ref_prefixes, "%.*s",
|
||||
(int)(glob - argv[i]), argv[i]);
|
||||
else
|
||||
expand_ref_prefix(&ref_prefixes, argv[i]);
|
||||
}
|
||||
}
|
||||
|
||||
|
@ -304,4 +304,13 @@ test_expect_success 'ls-remote works outside repository' '
|
||||
nongit git ls-remote dst.git
|
||||
'
|
||||
|
||||
test_expect_success 'ls-remote patterns work with all protocol versions' '
|
||||
git for-each-ref --format="%(objectname) %(refname)" \
|
||||
refs/heads/master refs/remotes/origin/master >expect &&
|
||||
git -c protocol.version=1 ls-remote . master >actual.v1 &&
|
||||
test_cmp expect actual.v1 &&
|
||||
git -c protocol.version=2 ls-remote . master >actual.v2 &&
|
||||
test_cmp expect actual.v2
|
||||
'
|
||||
|
||||
test_done
|
||||
|
Loading…
Reference in New Issue
Block a user