| commit | 9db5fb4fb352e79931e50f6de71497e273a3a6ac | |
| author | Jeff King <peff@peff.net> | |
| Wed, 15 Sep 2021 18:35:34 +0000 (15 14:35 -0400) | ||
| committer | Junio C Hamano <gitster@pobox.com> | |
| Wed, 15 Sep 2021 19:25:19 +0000 (15 12:25 -0700) | ||
| tree | cf0f43d9281a5e8a745de397c936de22df2b054f | treesnapshot (tar.gz zip) |
| parent | 7f0e4f6ac28b7a9494f3affd1336244d4fb0fe38 | commitdiff |
docs/protocol-v2: clarify some ls-refs ref-prefix details
We've never documented the fact that a client can provide multiple
ref-prefix capabilities. Let's describe the behavior.
We also never discussed the "best effort" nature of the prefixes. The
client side of git.git has always treated them this way, filtering the
result with local patterns. And indeed any client must do this, because
the prefix patterns are not sufficient to express the usual refspecs
(and so for "foo" we ask for "refs/heads/foo", "refs/tags/foo", and so
on).
So this may be considered a change in the spec with respect to client
expectations / requirements, but it's mostly codifying existing
behavior.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We've never documented the fact that a client can provide multiple
ref-prefix capabilities. Let's describe the behavior.
We also never discussed the "best effort" nature of the prefixes. The
client side of git.git has always treated them this way, filtering the
result with local patterns. And indeed any client must do this, because
the prefix patterns are not sufficient to express the usual refspecs
(and so for "foo" we ask for "refs/heads/foo", "refs/tags/foo", and so
on).
So this may be considered a change in the spec with respect to client
expectations / requirements, but it's mostly codifying existing
behavior.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
| Documentation/technical/protocol-v2.txt | diffblobblamehistory |