Re: [RFC][GSoC] Implement Generation Number v2
From: Junio C Hamano <hidden>
Date: 2020-03-24 21:13:49
Jakub Narebski [off-list ref] writes:
Junio C Hamano [off-list ref] writes:quoted
Jakub Narebski [off-list ref] writes:quoted
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.
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.