> > Firstly, I presume the generation number would not form part of the > SHA1 calculation? No? Cool. I suspect this may be where my suggestion falls down. Though I suspect there is a case for object metadata which doesn't form part of the SHA. Would generation number tampering be a concern? Caching offers the ability to store that metadata, to provide the same performance gain, but maintain the integrity of the SHA chain. However, it does still leave the generation number liable to tampering, meaning a generic non-SHA metadata solution might be better. TBH, there are few situations where historical generations are useful - finding gen numbers of tags is one of them. Most cases are going to be for new commits, and in that case, a few new commits at the tip of each branch will very quickly reduce the number of traversals. What use case would really create enough traversals that it should be a performance concern? -- 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