Re: Git commit generation numbers

From: Jakub Narebski <jnareb@gmail.com>
Date: Jul 22, 2011, 12:18 UTC
Message-ID: <201107221418.52414.jnareb@gmail.com>
In-Reply-To: <20110721202722.3765.qmail@science.horizon.com>

On Thu, 21 Jul 2011, George Spelvin wrote:

Show 7 quoted lines

> > There is also another issue that I have mentioned, namely incomplete
> > clones - which currently means shallow clone, without access to full
> > history.
> 
> As far as history walking is concerned, you can just consider "missing
> parent" the same as "no parent" and start the generation numbers at 0.
> As long as you recompute.

Well, shallow clone case can be considered both for putting 'true' generation numbers in commit header, and against it.

For, because with generation numbers in commits you can use true generation numbers.

Against, because if there are commits without generation numbers in header, you cannot assign true generation number, and you can only use "shallow" generation number, in generation numbers cache.

Show 10 quoted lines

> > Nb. grafts are so horrible hack that I would be not against turning
> > off generation numbers if they are used.
> 
> Yeah, but it's not too miserable to add support (the logic is very similar
> to replace objects), and then you would be able to have the history walking
> code depend on the presence of generation numbers.  (The "load the cache"
> function would regenerate it if necessary.)
> 
> Only do this if you already have support for "no generation numbers" in
> the history walking code for (say) loose objects.

Grafts are non-transferable, and if you use them to cull rather than add
history they are unsafe against garbage collection... I think.

Show 6 quoted lines

> > In the case of replace objects you need both non-replaced and replaced
> > DAG generation numbers.
> 
> Yes, the cache validity/invalidation criteria are the tricky bit.
> Honestly, this is where the code gets ugly, not computing and storing
> the generation numbers.

BTW. with storing generation number in commit header there is a problem what would old version of git, one which does not understand said header, do during rebase. Would it strip unknown headers, or would it copy generation number verbatim - which means that it can be incorrect?

BTW2. code size comparing in-commit and external cache cases must take into account yet to be written fsck for in-commit generation numbers.

-- 
Jakub Narebski
Poland