I strongly agree with Linus that the cache should not form part of the solution to this problem, but could maybe be a later add-on, which improved performance. There is a possible improvement, which may remove the need for the cache. It doesn't solve the issue of broken numbers, but I think the key to that is just to ensure the traversal algorithm is deterministic, stable, and immutable. Firstly, I presume the generation number would not form part of the SHA1 calculation? No? Cool. When calculating a generation number by doing a traversal, would it not be possible to update some, or all, commit objects touched, with their generation numbers. Again, this would be expensive, but there would possibly be even quicker gains than Linus's original proposal to just add numbers to the new commit. A compromise might be to only update some commits - notably those with 2 or more parents, so that both parents don't need to be traversed, and possibly every nth commit (to give regular checkpoints that can be utilised when traversing a branch). I would suggest commits with 2 children for the latter, but with my limited knowledge of the implementation, I understand that Is more difficult to find. Obviously, these numbers would only be pegged locally, and wouldn't by synced on push, as they already exist on the far end. However, it could be possible to run a process on a bare repo to shoot through and peg commits, then at least new clones will be "well pegged" Martin Long UK -- 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