Re: Generation numbers and replacement objects

On Fri, Jul 15, 2011, Jeff King wrote:

On Fri, Jul 15, 2011 at 02:01:36PM -0700, Jakub Narebski wrote:

quoted

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.
 

quoted

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.

quoted

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