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>

Jeff King committed Sep 15, 2021 at 14:35 UTC 9db5fb4fb352e79931e50f6de71497e273a3a6ac
1 file changed +5 -1
Documentation/technical/protocol-v2.txt
+5 -1
@@ -193,7 +193,11 @@ ls-refs takes in the following arguments:
193 Show peeled tags.
194 ref-prefix <prefix>
195 When specified, only references having a prefix matching one of
196 - the provided prefixes are displayed.
196 + the provided prefixes are displayed. Multiple instances may be
197 + given, in which case references matching any prefix will be
198 + shown. Note that this is purely for optimization; a server MAY
199 + show refs not matching the prefix if it chooses, and clients
200 + should filter the result themselves.
201
202 If the 'unborn' feature is advertised the following argument can be
203 included in the client's request.