Re: Request for detailed documentation of git pack protocol

From: Johannes Sixt <j6t@kdbg.org>
Date: Jun 3, 2009, 19:05 UTC
Message-ID: <200906032105.18459.j6t@kdbg.org>
In-Reply-To: <20090603144837.GE3355@spearce.org>

On Mittwoch, 3. Juni 2009, Shawn O. Pearce wrote:

Show 7 quoted lines

> We have a history of not leaving ourselves room for future expansion,
> and then needing to find a backdoor in the canonical implementation
> parser in order to make it work.
>
> In the protocol suite, its been the strlen() < pktlen trick which
> has generally worked.  Oh, and also sticking stuff after a fixed
> length record, where we didn't care.

This reminds me of one thing: upload-pack (of C git) sends a complete pack if and only if there were no errors, so that fetch-pack sees an error if upload-pack dies or if there is no side-band where upload-pack could signal an error (at least I think that are the reasons). There is a comment in upload-pack that explains a bit of it:

/* Data ready; we keep the last byte to ourselves
 * in case we detect broken rev-list, so that we
 * can leave the stream corrupted.  This is
 * unfortunate -- unpack-objects would happily
 * accept a valid packdata with trailing garbage,
 * so appending garbage after we pass all the
 * pack data is not good enough to signal
 * breakage to downstream.
 */

-- Hannes