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>maint
parent
e5af0de202
commit
a1e90b2352
|
@ -179,18 +179,19 @@ and descriptions.
|
||||||
|
|
||||||
Packfile Negotiation
|
Packfile Negotiation
|
||||||
--------------------
|
--------------------
|
||||||
After reference and capabilities discovery, the client can decide
|
After reference and capabilities discovery, the client can decide to
|
||||||
to terminate the connection by sending a flush-pkt, telling the
|
terminate the connection by sending a flush-pkt, telling the server it can
|
||||||
server it can now gracefully terminate (as happens with the ls-remote
|
now gracefully terminate, and disconnect, when it does not need any pack
|
||||||
command) or it can enter the negotiation phase, where the client and
|
data. This can happen with the ls-remote command, and also can happen when
|
||||||
server determine what the minimal packfile necessary for transport is.
|
the client already is up-to-date.
|
||||||
|
|
||||||
Once the client has the initial list of references that the server
|
Otherwise, it enters the negotiation phase, where the client and
|
||||||
has, as well as the list of capabilities, it will begin telling the
|
server determine what the minimal packfile necessary for transport is,
|
||||||
server what objects it wants and what objects it has, so the server
|
by telling the server what objects it wants and what objects it has,
|
||||||
can make a packfile that only contains the objects that the client needs.
|
so the server can make a packfile that only contains the objects that the
|
||||||
The client will also send a list of the capabilities it wants to be in
|
client needs. The client will also send a list of the capabilities it
|
||||||
effect, out of what the server said it could do with the first 'want' line.
|
wants to be in effect, out of what the server said it could do with the
|
||||||
|
first 'want' line.
|
||||||
|
|
||||||
----
|
----
|
||||||
upload-request = want-list
|
upload-request = want-list
|
||||||
|
@ -219,8 +220,8 @@ If client is requesting a shallow clone, it will now send a 'deepen'
|
||||||
line with the depth it is requesting.
|
line with the depth it is requesting.
|
||||||
|
|
||||||
Once all the "want"s (and optional 'deepen') are transferred,
|
Once all the "want"s (and optional 'deepen') are transferred,
|
||||||
clients MUST send a flush-pkt. If the client has all the references
|
clients MUST send a flush-pkt, to tell the server side that it is
|
||||||
on the server, client flushes and disconnects.
|
done sending the list.
|
||||||
|
|
||||||
TODO: shallow/unshallow response and document the deepen command in the ABNF.
|
TODO: shallow/unshallow response and document the deepen command in the ABNF.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue