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 -- 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