On Wed, Jul 06, 2011 at 04:22:23PM -0700, Junio C Hamano wrote: > As to the low level implementation detail I agree everything you said, but > I have been wondering how the generation number should intereact with > grafts and replaces. It certainly would be safest whenever you change > grafts (which should be a rare event anyway). Ugh. I hadn't even considered grafting. Yeah, grafting or replacing could make the generation numbers totally wrong. And not just for the replaced commit, but for everything that builds on top. That's perhaps an argument against putting them into the commit header at all; once you graft, everything after will have bogus generation numbers. So yeah, you would want to clear the cache any time you tweak replacements or grafts (which I think is what you were saying in your final sentence). You could do a hybrid solution, in which you have generation numbers in the commit header, and an external cache. You need the cache anyway to support older commits without the header. And then you could use the built-in generation numbers when there's no grafting or replacing going on, and the cache otherwise. That keeps the common case (no grafts) faster. Still, if we can get the external lookup to be faster than my initial notes attempt (which really should not be that hard), the performance difference may not end up that big, and it won't even be worth putting them into the header at all. -Peff -- 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