Ok we actually have a small problem, semi-related to the object listing. By default rev-list will list everything not seen in each tree, whereas rev-cache will only list object introduced in a given commit. This becomes problematic if you have two different files with the same content in the same tree: rev-cache will show the name of the youngest file; vanilla rev-list will list the name soonest encountered in the tree (which can even change if, e.g., a subdir is renamed so as to be list in a different order). In fact, even if they're not in the same tree we could have a similar problem. Commits are stored topologically in cache slices, so output is always in topo order. If the same object is introduced in parallel branches under different names, the outputted name with `rev-list --all --objects` (vanilla) could be different from `rev-list --all --objects` (cached) could be different from `rev-list --all --topo-order --objects`. This isn't feasably changable in rev-cache, as a) the cached position (and hence final output order) is effectively unrelated to tree structure, and b) commits _have_ to be ordered topologically for rev-cache to function. The descrepency strikes me as something of a non-issue with pack-objects' deltafication, as the object will fit with either of its names. It will mean that the (already sorta finicky) object names won't have garuanteed consistency between cached/non-cached calls to rev-list. This is something of a corner case and dosn't strike me as a huge issue, but I figured I should consult you all before presuming things about git's interface. - Nick -- 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