On Fri, 2009-08-21 at 17:07 -0400, Nicolas Pitre wrote: > > 2. There is support in git pack format to do 'deepening' of shallow > > clone, which means that git can generate incrementals in top-down > > order, _similar to how objects are ordered in packfile_. > > Well... the pack format was not meant for that "support". The fact > that > the typical object order used by pack-objects when serving fetch > request > is amenable to incremental top-down updates is rather coincidental > and > not really planned. Mmm. And the problem with 'thin' packs is that they normally allow deltas the other way. 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. > > Another solution would be to try to come up with some sort of stable > > sorting of objects so that packfile generated for the same > > parameters (endpoints) would be always byte-for-byte the same. But > > that might be difficult, or even impossible. > > And I don't want to commit to that either. Having some flexibility > in object ordering makes it possible to improve on the packing > heuristics. You don't have to lose that for storage. It's only for generating the thin packs that it matters; also, the restriction is relaxed when it comes to objects which are all being sent in the same pack, which can freely delta amongst themselves in any direction. What did you think about the bundle slicing stuff? 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