Re: [RFC PATCH v4 06/26] Add multi_ack_detailed capability to fetch-pack/upload-pack

"Shawn O. Pearce" [off-list ref] 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.