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

[Nick Edelen <sirnot@gmail.com>]

> Result with the rev-cache populated returns the same number of
> revisions, but not the same amount of data.
> [...]
> So... Why is the leading path component dropped sometimes?  That
> explains the output size difference.  And the drop is not coherent
> either:

It looks like I didn't realize that tree_entry() returns only the
entry name, and not the full path, which seems like a case of not
thinking, just being logical.  The unit tests didn't catch it b/c it
only occurs for root commits, and none of the root commits in the test
had directories involved.

> The object order appears to be rather different.  Why so?

The non-commit object order has to be different because they're added
in a different way.  It's sorta like vanilla rev-list ordering, except
objects are /only/ appended that are introduced per current commit,
rather than all that haven't been seen yet.  It's still a coherent
ordering, and despite the different mechanism I've still enforced the
tag-tree-blob ordering of the normal rev-list.

I've fixed the name issue and added that scenario to the unit tests.
I'll re-upload this last patch in a bit (either minutes if my flight
dosn't leave soon or hours if so).

 - Nick