Re: [RFC][GSoC] Implement Generation Number v2

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 24, 2020, 21:13 UTC
Message-ID: <xmqq8sjp1mnz.fsf@gitster.c.googlers.com>
In-Reply-To: <86k139ahb7.fsf@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

Show 16 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> About moving commit data with generation number v2 to "CDA2" chunk: if
>>> "CDAT" chunk is missing then (I think) old Git would simply not use
>>> commit-graph file at all; it may crash, but I don't think so.  If "CDAT"
>>> chunk has zero length... I don't know what would happen then, possibly
>>> also old Git would simply not use commit-graph data at all.
>>
>> Yeah, if it makes it crash, then we cannot use that "missing CDAT"
>> approach.
>
> I have not tested this, but from reading the code it looks like "missing
> CDAT" makes Git fail softly -- it would return NULL for the
> commit-graph, and thus not use commit-graph data at all... which might
> be too high a price (too high performance penalty for old Git).

Oh, that would not make me worried an iota. If anything, it encourages adoption of the new version ;-) As long as the correctness is not violated, it is fine as a fallback behaviour.

Show 5 quoted lines

> On the other hand computing generation number v1 (topological level) and
> generation number v2 ([monotonic] offset for corrected commit date)
> should not be much more costly than calculating single generation
> number, assuming that most of the cost is walking the commit graph.  But
> this would need benchmarking.

Good point. If we can do so cheaply enough, there is no reason to omit the v1 data from the file and stuff placeholder 0 in these fields.

> Also, as Stolee wrote, with generation number v2 in separate chunk we
> have commit data not together, but split into two areas.

Yes, that is a problem. The "empty CDAT with everything not just generation numbers in CDA2" approach would help us move forward with v2, while not harming older version of Git. Just like pack bitmap, commit-graph is designed to be a local optimization matter, and worrying about older Git not being able to use the optimization hints left by newer version of Git is not useful. Quite honestly, the only two things we should make sure are that the repository does not appear corrupt and unusable by current Git when it has graph files with new generation number scheme, and that manipulations by current Git of a repository with newer graph files will not corrupt the repository for current or newer Git.

Thanks.