Re: Repacking many disconnected blobs

On Wed, 14 Jun 2006, Keith Packard wrote:

On Wed, 2006-06-14 at 11:18 -0700, Linus Torvalds wrote:

quoted

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