Junio C Hamano <gitster@xxxxxxxxx> wrote: > "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? No, I mean "object exists". The upload-pack code makes no check that the object is in fact complete, just that it has the object in the object database. The object could be a dangling commit whose parents aren't present, and we'd still (currently) return an "ACK %s" for it. I specifically didn't get into completeness here because we don't actually check for it. > > 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. "ACK $it ready" should be used when ok_to_give_up() returns true. The "ACK $it ready" message is trying to say "don't talk any more about things reachable from $it, and by the way, if you say 'done' now I will give you a pack". The "ACK $it common" message is trying to say "$it is a common base, don't talk any more about things reachable from $it, but there may be other branches you should explore before I send you a pack, so talk about those if you can". A client only wants to store $it into its request state vector for replay on the next RPC if $it is truely common. The "ACK $it common" before "ACK $it ready" is because clients can't assume that "ACK $it ready" means $it is really common. Servers send "ACK $it ready" if they don't have $it but are ok_to_give_up(). But if it is common, *and* ok_to_give_up() is true, a server can send both messages, but it must send "ACK $it common" first. -- Shawn. -- 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