mirrors/git
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'nd/http-fetch-shallow-fix'

Browse Source 
Attempting to deepen a shallow repository by fetching over smart
HTTP transport failed in the protocol exchange, when no-done
extension was used.  The fetching side waited for the list of
shallow boundary commits after the sending end stopped talking to
it.

* nd/http-fetch-shallow-fix:
  t5537: move http tests out to t5539
  fetch-pack: fix deepen shallow over smart http with no-done cap
  protocol-capabilities.txt: document no-done
  protocol-capabilities.txt: refer multi_ack_detailed back to pack-protocol.txt
  pack-protocol.txt: clarify 'obj-id' in the last ACK after 'done'
  test: rename http fetch and push test files
This commit is contained in:
Junio C Hamano
2014-02-27 14:01:50 -08:00
parent 0f9e62e084 0232852b06
commit 2de34784df
9 changed files with 104 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
Documentation/technical/pack-protocol.txt
View File

@ -338,7 +338,8 @@ during a prior round. This helps to ensure that at least one common
ancestor is found before we give up entirely.
Once the 'done' line is read from the client, the server will either
send a final 'ACK obj-id' or it will send a 'NAK'. The server only sends
send a final 'ACK obj-id' or it will send a 'NAK'. 'obj-id' is the object
name of the last commit determined to be common. The server only sends
ACK after 'done' if there is at least one common base and multi_ack or
multi_ack_detailed is enabled. The server always sends NAK after 'done'
if there is no common base found.

18
Documentation/technical/protocol-capabilities.txt
View File

@ -69,6 +69,24 @@ ends.
Without multi_ack the client would have sent that c-b-a chain anyway,
interleaved with S-R-Q.
multi_ack_detailed
------------------
This is an extension of multi_ack that permits client to better
understand the server's in-memory state. See pack-protocol.txt,
section "Packfile Negotiation" for more information.
no-done
-------
This capability should only be used with the smart HTTP protocol. If
multi_ack_detailed and no-done are both present, then the sender is
free to immediately send a pack following its first "ACK obj-id ready"
message.
Without no-done in the smart HTTP protocol, the server session would
end and the client has to make another trip to send "done" before
the server can send the pack. no-done removes the last round and
thus slightly reduces latency.
thin-pack
---------