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

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