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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html