From: Eric Sunshine <ericsunshine@gmail.com>
Date: Wed, 13 Jul 2011 14:26:19 GMT
Subject: Re: [RFC/PATCHv2 3/6] commit: add commit_generation function
Message-ID: <4E1DAB0B.4020109@gmail.com>
In-Reply-To: <20110713070517.GC18566@sigill.intra.peff.net>

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