Re: Generation numbers and replacement objects

[Jakub Narebski <jnareb@gmail.com>]

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