[PATCH 1/3] Document protocol capabilities extension

[Stefan Beller <sbeller@google.com>]

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@google.com>
---
 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