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

[Nick Edelen <sirnot@gmail.com>]

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