On 7/13/2011 3:05 AM, Jeff King wrote:
A commit's generation is its height in the history graph, as
measured from the farthest root. It is defined as:
- Otherwise, its generation is 1 more than the maximum of
its parents generations.
Possessive: s/parents/parents'/
We could also store generation numbers in the commit header
directly. These would be faster to look at than an external
cache (they would be on par speed-wise with commit
timestamps). But there are a few reasons not to:
2. With grafts and replacement objects, the graph
structure (and thus the generation numbers) can be
changed. So the generation number, while immutable for
a given commit object, can be changed when we "lie"
about the graph structure via these mechanisms. Being
able to simply clear the cache when these things are
changed is helpful.
Would this be clearer? "Being able to rebuild the cache when..."
-- ES
--
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