Re: A look at some alternative PACK file encodings

From: Richard Curnow <rc@rc0.org.uk>
Date: Sep 7, 2006, 14:39 UTC
Message-ID: <loom.20060907T163036-849@post.gmane.org>
In-Reply-To: <20060907133456.24226.qmail@science.horizon.com>

 <linux <at> horizon.com> writes:

> 
> For regular packs, such objects wouldn't even be present, because
> all base objects are in the pack itself.
>

It would actually be useful if this restriction were lifted.

Granted, for working repositories there's not much point, because 'git repack -a -d' can be run regularly these days.

But for repositories served by the dumb http:// transport it makes some sense. You don't want to run 'repack -a -d' on those, because anybody tracking them ends up having to download the entire history again every time they pull. But if you pack too often, you incur the cost of the packs containing lots of base objects - it's as though the delta chain lengths can only ever be about 1 or 2.

If the packs were thin, regular pullers would already have the base objects, and occasional pullers would just have to download more of the intervening (thin) packs to get the missing deltas in the middle of the chains. (I think everyone has to download all the .idx files in any case.)