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