Re: Continue git clone after interruption

[Sam Vilain <sam@vilain.net>]

On Fri, 2009-08-21 at 23:37 -0400, Nicolas Pitre wrote:
> What did you think about the bundle slicing stuff?
> 
> If I didn't comment on it already, then I probably missed it and have no 
> idea.

I really tire of repeating myself for your sole benefit.  Please show
some consideration for other people in the conversation by trying to
listen.  Thank-you.

> > I think the first step here would be to allow thin pack generation to
> > accept a bounded range of commits, any of the objects within which may
> > be used as delta base candidates.  That way, these "top down" thin packs
> > can be generated.  Currently of course it just uses the --not and makes
> > "bottom up" thin packs.
> 
> The pack is still almost top-down.  It's only the missing delta base 
> that are in the other direction, refering to objects you have locally 
> and therefore older.

Ok, but right now there's no way to specify that you want a thin pack,
where the allowable base objects are *newer* than the commit range you
wish to include.

What I said in my other e-mail where I showed how well it works taking
a given bundle, and slicing it into a series of thin packs, was that it
seems to add a bit of extra size to the resultant packs - best I got for
slicing up the entire git.git run was about 20%.  If this can be
reduced to under 10% (say), then sending bundle slices would be quite
reasonable by default for the benefit of making large fetches
restartable, or even spreadable across multiple mirrors.

The object sorting stuff is something of a distraction; it's required
for download spreading but not for the case at hand now.

Sam