Jeff King <peff@xxxxxxxx> writes: > Yeah, that would be fine. With a sorted list of binary sha1s and 32-bit > generation numbers, you're talking about 24 bytes per commit. Or a 6 > megabyte cache for linux-2.6. > > You'd probably want to be a little clever with updates. If I have > calculated the generation number of every commit, and then do "git > commit; git tag --contains HEAD", you probably don't want to rewrite the > entire cache. You could probably journal a fixed number of entries in an > unsorted file (or even in a parallel directory structure to loose > objects), and then periodically write out the whole sorted list when the > journal gets too big. Or choose a more clever data structure that can do > in-place updates. As to the low level implementation detail I agree everything you said, but I have been wondering how the generation number should intereact with grafts and replaces. It certainly would be safest whenever you change grafts (which should be a rare event anyway). -- 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