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

[Jakub Narebski <jnareb@gmail.com>]

"Shawn O. Pearce" <spearce@spearce.org> 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