From: Sam Vilain <sam@vilain.net>
Date: Fri, 07 Aug 2009 03:22:19 GMT
Subject: Re: [PATCH 5/5] full integration of rev-cache into git's revision walker, completed test suite
Message-ID: <4A7B9DEB.1060002@vilain.net>
In-Reply-To: <op.ux8i7ceotdk399@sirnot.private>

Nick Edelen wrote:
> This last patch provides a working integration of rev-cache into the revision 
> walker, along with some touch-ups:
>   

"This last patch" is redundant.  You can just write "Integrate rev-cache
into the revision walker;"

>  - integration into revision walker and list-objects
>  - addition of 'unique' field to commit objects, optionally initialized in 
>    rev-cache with the objects introduced in that commit
>  - tweak of object generation to take advantage of the 'unique' field
>  - more fluid handling of damaged cache slices
>  - numerous tests for both features from the previous patch, and the 
> integration's integrity
>   

Does it make sense to split this integration up or stage it somehow?

> 'Integration' is rather broad -- a more detailed description follows for each 
> aspect:
>  - rev-cache
> the traversal mechanism is updated to handle many of the non-prune options 
> rev-list does (date limiting, slop-handling, etc.), and is adjusted to allow 
> for non-fatal cache-traversal failures.
>
>  - revision walker
> both limited and unlimited traversal attempt to use the cache when possible, 
> smoothly falling back if it's not.
>
>  - list-objects
> object listing does not recurse into cached trees, and has been adjusted to 
> guarantee commit-tag-tree-blob ordering.
>   

Especially given the length of this part of the commit message.

Sam