> Comments? This is pretty simplistic, and yes, it's slow. On the kernel, it
> now takes a few seconds to generate a new commit when there are no
> generation numbers - and that's on a fast machine.
I agree this is the way to go if we _were_ to use generation number
associated with commit objects in the longer term, and if the SLOP
logic in still_interesting() in revision.c:
(1) can gracefully fall back to the date based heuristics for older
commits without the header; and
(2) can take advantage of the generation numbers in more recent commit.
If we cannot do (1), we could augment this with Peff's generation number
cache. I suspect (1) is doable and in that case we do not have to have
(and we may be better off without) the on-disk cache that could go stale,
but nobody so far has shown that yet, so...
As I mentioned in a review comment of the actual patch, I however am not
convinced that generation number is a better substitute for the timestamp
in the context of "tag --contains" optimization.
--
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