On Fri, Jul 15, 2011, Jeff King wrote: > 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). Actually we wouldn't probably want a separate cache for each validity token, but two caches: one with and one without... well, perhaps one per namespace. But certainly not one per replacement. > > 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. I tried, but he isn't responding to questions about replacement objects. I can agree that grafts are terrible hack, and for me turning off using generation numbers if there are grafts is reasonable solution. Not so with replace objects. > > 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. True. Well, at least taking hash of only replacements of commit objects that change generation number could be a reasonable thing... but probably too complicated anyway. -- 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