"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > IIRC, without multi_ack, a client sends have lines in --date-order > until the server has found a common base. That means the client > will send have lines that are already known by the server to be > common, because they overlap in time with another branch that the > server hasn't found a common base on yet. > > E.g. the client has things in caps that the server doesn't; server > has things in lower case: > > +---- u ---------------------- x > / +----- y > / / > a -- b -- c -- d -- E -- F > \ > +--- Q -- R -- S > > If the client wants x,y and starts out by saying have F,S, the > server doesn't know what F,S is. Eventually the client says "have > d" and the server sends "ACK d continue" to let the client know to > stop walking down that line (so don't send c-b-a), but its not done > yet, it needs a base for X. The client keeps going with S-R-Q, > until a gets reached, at which point the server has a clear base > and it all ends. > > Without multi_ack the client would have sent that c-b-a chain anyway, > interleaved with S-R-Q. > > Junio, am I right? Correct. >> >> * thin-pack >> >> Server can send thin packs, i.e. packs which do not contain base >> elements, if those base elements are available on clients side. >> Client has thin-pack capability when it understand how to "thicken" >> them adding required delta bases making them independent. > > Yes. > >> Of course it doesn't make sense for client to use (request) this >> capability for git-clone. > > No, no it doesn't. But if the client does request it (and I think > modern clients actually do request it, even on initial clone case) > the server won't produce a thin pack. Why? There is no common base, > so there is no uninteresting set to omit from the pack. :-) There also is "clone --reference". > Actually, it has to be, because that "\n" isn't there on the first > line when the capability data appears either wedged behind the "\0" > or after the " " at the end of the line. Correct. > Its ugly. But basically you keep a running counter of each "flush" > sent, and then you send a "done" out, and then you wait until > you have the right number of ACK/NAK answers back, and then the > stream changes format. One thing that I did not see mentioned in this thread is that the implementation is allowed to buffer non-flush packets and send multiple of them out with a single write(2). In other words, packet_write() could buffer instead of directly calling safe_write(), while packet_flush() must do safe_write() and make sure it drains. -- 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