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