Re: Repacking many disconnected blobs

From: Nicolas Pitre <nico@cam.org>
Date: Jun 14, 2006, 19:25 UTC
Message-ID: <Pine.LNX.4.64.0606141514000.2703@localhost.localdomain>
In-Reply-To: <1150311567.30681.28.camel@neko.keithp.com>

On Wed, 14 Jun 2006, Keith Packard wrote:

Show 16 quoted lines

> On Wed, 2006-06-14 at 11:18 -0700, Linus Torvalds wrote:
> 
> > You don't _need_ to shuffle. As mentioned, it will only affect the 
> > location of the data in the pack-file, which in turn will mostly matter 
> > as an IO pattern thing, not anything really fundamental.  If the pack-file 
> > ends up caching well, the IO patterns obviously will never matter.
> 
> Ok, sounds like shuffling isn't necessary; the only benefit packing
> gains me is to reduce the size of each directory in the object store;
> the process I follow is to construct blobs for every revision, then just
> use the sha1 values to construct an index for each commit. I never
> actually look at the blobs myself, so IO access patterns aren't
> relevant.
> 
> Repacking after the import is completed should undo whatever horror show
> I've created in any case.

The only advantage of feeding object names from latest to oldest has to do with the delta direction. In doing so the delta are backward such that objects with deeper delta chain are further back in history and this is what you want in the final pack for faster access to the latest revision.

Of course the final repack will do that automatically, but only if you use -a -f with git-repack. But when -f is not provided then already deltified objects from other packs are copied as is without any delta computation making the repack process lots faster. In that case it might be preferable that the reuse of already deltified data is made of backward delta which is the reason you might consider feeding object in the prefered order up front.

Nicolas