Subject: Re: [RFC/PATCHv2 3/6] commit: add commit_generation function

From: Eric Sunshine <[email-masked]>
Date: Wed, 13 Jul 2011 10:26:19 -0400

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