In the future we may want to have multiple different versions for the transport protocol each optimized for a certain aspect of the transport such as latency, bandwidth, CPU load etc. To make this future proof document a possible way how to advertise the versions such that the client can store it and use try to use such advertised protocols later if the clients supports them. Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx> --- Documentation/technical/protocol-capabilities.txt | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index 4f8a7bf..6829668 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -268,3 +268,14 @@ to accept a signed push certificate, and asks the <nonce> to be included in the push certificate. A send-pack client MUST NOT send a push-cert packet unless the receive-pack server advertises this capability. + +versions +-------- + +If the server supports more than the standard protocol, this capability +advertises the additional versions. It is a comma separated list of +the names of extensions for the binaries (i.e. "v2" would result in +the assumption that git-receive-pack-v2 as well as git-upload-pack-v2 +is available). The items are desired in desceding order by the server, +i.e. the server would like the client to use the first advertised +version most. -- 2.3.0.81.gc37f363 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html