Jeff King <peff@xxxxxxxx> writes: > It takes barely any time to get the generation of the new commit, but we > spend .25 seconds writing the whole new cache file out. This could be > improved with a more clever disk format that contained a journal of > unsorted newly written entries. You'd still write the full cache out > once in a while, but the cost would be amortized. This series consists of three somewhat related ideas: - A generic API to persistently annotate 20-byte keys (typically object names); - Using that API to implement commit generation numbers; - Using commit generation numbers in "tag --contains" traversal. I think the first one is independently a good change, but I have been wondering if the entire history needs to be annotated with the generation number for the goal of the third item. There may be stretches of history where timestamps are screwed up, but if the commits we should dig through while traversing (because they, their parents or their children record skewed timestamps) are minority in the history, the same generic API could be used to mark only these commits as such, by using far smaller number of disk I/Os, no? -- 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