"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > ACK %s > ----------------------------------- > * no multi_ack or multi_ack_detailed: > > Sent in response to "have" when the object exists on the remote > side and is therefore an object in common between the peers. > The argument is the SHA-1 of the common object. Do you mean by "exists" something a bit stronger than that, namely, it exists and everything reachable from it also exists, right? > ACK %s common > ----------------------------------- > * multi_ack_detailed only: > > Sent in response to "have". Both sides have this object. > Like with "ACK %s continue" above the client should stop > sending have lines reachable for objects from the argument. > > ACK %s ready > ----------------------------------- > * multi_ack_detailed only: > > Sent in response to "have". > > The client should stop transmitting objects which are reachable > from the argument, and send "done" soon to get the objects. > > If the remote side has the specified object, it should > first send an "ACK %s common" message prior to sending > "ACK %s ready". > > Clients may still submit additional "have" lines if there are > more side branches for the client to explore that might be added > to the common set and reduce the number of objects to transfer. I do not understand this after reading it three times. The remote side says "ACK $it common", allow the requestor to feed more "have", then eventually send an "ACK $it ready" for the same object it earlier sent "common" for? The first one tells the requestor not to go down the path from $it further, so presumably all the "have"s that come after it will be about different ancestry paths. What is the advantage of using this? In other words, how, in what situation and why would the remote side choose to use "ready" --- it looks to me that it could always say "common" whenever it hits a "have" that it can determine to be common. -- 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