9db5fb4fb3
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> |
||
---|---|---|
.. | ||
.gitignore | ||
api-error-handling.txt | ||
api-index-skel.txt | ||
api-index.sh | ||
api-merge.txt | ||
api-parse-options.txt | ||
api-simple-ipc.txt | ||
api-trace2.txt | ||
bitmap-format.txt | ||
bundle-format.txt | ||
chunk-format.txt | ||
commit-graph-format.txt | ||
commit-graph.txt | ||
directory-rename-detection.txt | ||
hash-function-transition.txt | ||
http-protocol.txt | ||
index-format.txt | ||
long-running-process-protocol.txt | ||
multi-pack-index.txt | ||
pack-format.txt | ||
pack-heuristics.txt | ||
pack-protocol.txt | ||
packfile-uri.txt | ||
parallel-checkout.txt | ||
partial-clone.txt | ||
protocol-capabilities.txt | ||
protocol-common.txt | ||
protocol-v2.txt | ||
racy-git.txt | ||
reftable.txt | ||
remembering-renames.txt | ||
repository-version.txt | ||
rerere.txt | ||
send-pack-pipeline.txt | ||
shallow.txt | ||
signature-format.txt | ||
sparse-index.txt | ||
trivial-merge.txt |