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

Junio C Hamano [off-list ref] wrote:

"Shawn O. Pearce" [off-list ref] writes:

quoted

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.
 

quoted

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.