Re: Git network protocol

From: Junio C Hamano <junkio@cox.net>
Date: Aug 14, 2006, 06:42 UTC
Message-ID: <7vk65bg6na.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060814062117.GC10476@josefsipek.net>

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, and "git show 1bd8c8f0".

> So, I can _assume_ that "done" tells the server that it is time to make a
> pack. Why does the server use NAK during the clone operation, but ACK
> during fetch? Why does the server ACK the same SHA1 twice? And why does the
> client "want" the same SHA1 twice? It just seems odd.

During the initial "SHA-1 name"/"want" exchange, the server and the client negotiate the protocol extension (the document needs to be updated at least for "multi-ack" extension).

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.

The client can send "flush" -- this asks the server to give NAK if more "have"s need to be sent. If there is no more "have"s to be sent, "done" is sent.

The protocol streams; if you see an ACK from server it does not usually mean it is ACKing the last 'have' client has sent.