Re: [PATCH 6/6 (v4)] support for path name caching in rev-cache

> 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.