Re: [RFC/PATCHv2 6/6] limit "contains" traversals based on commit generation

Jeff King [off-list ref] 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?