On Fri, Jul 15, 2011 at 02:01:36PM -0700, Jakub Narebski wrote: > Peff, as Junio said somewhere else either in this thread, or the one > started by Linus, we would want generation numbers both without taking > into account replacement objects (e.g. for object traversal during > push / fetch), and with taking it into account (e.g. when showing log > or blame for end user). > > So we would need two generation number caches: one with and one > without replaces. Right. And I already outlined a solution for that by indexing the caches by the validity token (I haven't written the patches yet, but it's a pretty trivial change). > Nb. generation header stored in commit object can give only the one > without replaces, i.e. speed up object enumeration (what happened to > caching GSoC project code?) but not git-log. Yes. It is a weakness of putting the generation number in the header. I think Linus has already said he doesn't care about grafting. You are welcome to argue with him about that. > Also if replacement object has the same generation as the commit it > replaces, and I think also if it has lower generation number, current > generation numbers would still work (ne need to invalidate cache). Yes, that is why I said elsewhere "you could be more clever about seeing how the cache's validity constraints changed". But ultimately, it is not that expensive to regenerate the cache under the new conditions, grafts don't change very often, and the code to figure out exactly which parts of the cache could be saved would be complex. -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