Fix documentation of fetch-pack that implies that the client can disconnect after sending wants.
Specify conditions under which the client can terminate the connection early. Previously, an unintended behavior was possible which could confuse servers. Based-on-patch-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Alex Neronskiy <zakmagnus@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Alex Neronskiy committed
Jun 8, 2011 at 15:11 UTC
a1e90b2352f9f45293d3d439270f81607284ca9a
1 file changed
+15
-14
Documentation/technical/pack-protocol.txt
+15
-14
@@ -179,18 +179,19 @@ and descriptions.
179
180
Packfile Negotiation
181
--------------------
182
-After reference and capabilities discovery, the client can decide
183
-to terminate the connection by sending a flush-pkt, telling the
184
-server it can now gracefully terminate (as happens with the ls-remote
185
-command) or it can enter the negotiation phase, where the client and
186
-server determine what the minimal packfile necessary for transport is.
187
-
188
-Once the client has the initial list of references that the server
189
-has, as well as the list of capabilities, it will begin telling the
190
-server what objects it wants and what objects it has, so the server
191
-can make a packfile that only contains the objects that the client needs.
192
-The client will also send a list of the capabilities it wants to be in
193
-effect, out of what the server said it could do with the first 'want' line.
182
+After reference and capabilities discovery, the client can decide to
183
+terminate the connection by sending a flush-pkt, telling the server it can
184
+now gracefully terminate, and disconnect, when it does not need any pack
185
+data. This can happen with the ls-remote command, and also can happen when
186
+the client already is up-to-date.
187
+
188
+Otherwise, it enters the negotiation phase, where the client and
189
+server determine what the minimal packfile necessary for transport is,
190
+by telling the server what objects it wants and what objects it has,
191
+so the server can make a packfile that only contains the objects that the
192
+client needs. The client will also send a list of the capabilities it
193
+wants to be in effect, out of what the server said it could do with the
194
+first 'want' line.
195
196
----
197
upload-request = want-list
@@ -219,8 +220,8 @@ If client is requesting a shallow clone, it will now send a 'deepen'
220
line with the depth it is requesting.
221
222
Once all the "want"s (and optional 'deepen') are transferred,
222
-clients MUST send a flush-pkt. If the client has all the references
223
-on the server, client flushes and disconnects.
223
+clients MUST send a flush-pkt, to tell the server side that it is
224
+done sending the list.
225
226
TODO: shallow/unshallow response and document the deepen command in the ABNF.
227