I can see the logic behind Johannes's ideas, but I'm still not sure it'd be a great modification. If you wanted to associate revision caching much more strongly with packs, then packs and slices could be merged reasonably well. Say you just attached the actual slice data at the end of the pack, then stored offsets of the slice payload in the pack index. Since you'd (presumably) have to search the index for the object anyway, you wouldn't have to deal with searching a rev-cache index on top of that (although it's not exactly unoptimized now). However, that would sorta be preemptively limiting rev-cache to pack-related optimizations. I mean at the moment that's the main target, but it could be improved in the future to be more relavant to other operations as well. Leaving the rev-cache as a seperate system would keep both it and packing much more flexible, and open to longer-term developments. >I haven't read the side of the patch that _uses_ the information stored in >the rev-cache to figure out what it optimizes and what its limitations are >(e.g. how it interacts with pathspecs). Perhaps the rev-cache may turn >out to be _only_ useful for pack-objects and nothing else, in which case >we may not care about standalone version of rev-cache generator after all. rev-cache's cache slice traversal basically emulates git's revision walker, on a smaller scale. At the moment it only really handles date limiting (and obviously slop stuff) so it's not used for any pruning. That's not to say it couldn't be updated in the future though. -- 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