Re: [RFC PATCH v2 05/16] Add multi_ack_2 capability to fetch-pack/upload-pack

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

When multi_ack_2 is enabled the ACK continue messages returned by the
remote upload-pack are broken out to describe the different states
within the peer.  This permits the client to better understand the
server's in-memory state.

Errr... can't you find better name than multi_ack_2?  Perhaps
multi_ack_detailed or something...

The fetch-pack/upload-pack protocol now looks like:

[...]

ACK %s continue
-----------------------------------
  * multi_ack only:

    Sent in response to "have".

    The remote side wants the client to consider this object as
    common, and immediately stop transmitting additional "have"
    lines for objects that are reachable from it.  The reason
    the client should stop is not given, but is one of the two
    cases below available under multi_ack_2.

ACK %s common
-----------------------------------
  * multi_ack_2 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_2 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.

-- 
Jakub Narebski
Poland
ShadeHawk on #git