Re: Git network protocol

From: Josef "Jeff" Sipek <jeffpc@josefsipek.net>
Date: Aug 14, 2006, 23:48 UTC
Message-ID: <20060814234826.GA21861@josefsipek.net>
In-Reply-To: <7vk65bg6na.fsf@assigned-by-dhcp.cox.net>

On Sun, Aug 13, 2006 at 11:42:33PM -0700, Junio C Hamano wrote:

Show 7 quoted lines

> jeffpc@josefsipek.net (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.

Show 11 quoted lines

> 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.