On Thu, 7 Jul 2011, Jeff King wrote: > 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. Or we could enhance pack protocol (new capability) to send generation notes cache as a separate stream perhaps. Or make generation notes cache part of post-downloading work, after (or while) generating pack index. > 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. I wonder if we can reuse pack index code / format somewhat. Or perhaps some kind of on-disk hash table; we need O(1) fast lookup, and ability to update structure 'in place'. -- Jakub Narebski Poland -- 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