On Sun, Aug 13, 2006 at 11:42:33PM -0700, Junio C Hamano wrote: > jeffpc@xxxxxxxxxxxxxx (Josef "Jeff" Sipek) writes: > > > I'm trying to implement the git protocol, and I am having a bit of an issue > > with the lack of information available about it (please correct me if I > > missed some source of information.) > > Documentation/technical/pack-protocol.txt This is pretty much a vague example - or at least it feels vague if you don't know the protocol. After reading the source, and your description, the example makes a lot more sense. > "git show 1bd8c8f0". Neat. > After that, the client and the server try to determine what > commits the client has that are recent ancestors of "want" > commits. This exchange is done by client sending bunch of > "have" to the server. The server responds "ACK" (in the > original protocol) to say "I've seen enough and know a common > ancestor to use". In multi-ack protocol (which is used in > modern git, v0.99.9 and later), the server can respond "ACK > continue" to say "I've seen enough on that branch so do not > bother sending 'have's for its ancestors, but do keep sending > from other branch." If the server does not feel it saw enough, > it does not send either. So, if I understand this correctly, multi_ack allows for multiple branches to be fetched using the same connection? > The protocol streams; if you see an ACK from server it does not > usually mean it is ACKing the last 'have' client has sent. Yeah, makes sense. Doing things over lo does things like that - I'm not sure why I didn't realize it earlier. Thanks, Josef "Jeff" Sipek. -- Don't drink and derive. Alcohol and algebra don't mix. - 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