On Sat, 22 Aug 2009, Sam Vilain wrote: > 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. Sure. The pack format is flexible. > 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. > > > 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; What 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. That's always the case within a pack, but only for REF_DELTA objects. The OFS_DELTA objects have to be ordered. And yes, having deltas across packs is disallowed to avoid cycles and to keep the database robust. The only exception is for thin packs, but those are never created on disk. Thin packs are only used for transport and quickly "fixed" upon reception by appending the missing objects to them so they are not "thin" anymore. > 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. Nicolas -- 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