On Sun, Mar 22, 2020 at 10:32:32PM -0700, Junio C Hamano wrote: > Abhishek Kumar <abhishekkumar8222@xxxxxxxxx> writes: > > >> Unfortunately for the time being we cannot use commit-graph format > >> version; the idea that was proposed on the mailing list (when we found > >> about the bug in handling commit-graph versioning, during incremental > >> commit-graph implementation), was to create and use metadata chunk or > >> versioning chunk (the final version of incremental format do not use > >> this mechanism). This could be used by gen2 compatibile Git to > >> distinguish between situation where old commit-graph file to be updated > >> uses generation number v1, and when it uses v2. > >> > >> If you have a better idea, please say so. > > > > We could also use a flag file. Here's how it works: > > > > If the file `.git/info/generation-number-v2` exists, use gen2. > > Otherwise use gen1. > > If the file is lost then we will try to read the other file that has > the commit-graph data as if it were in old format? And if such a > file was created (say, with "touch .git/info/generation-number-v2"), > a file in the original format will be read as if it is in new > format? If that is the case, it is likely that we'd see a segfault; > sounds too brittle to me. Agreed. Flag file has too many issues to be pursued further. > > It appears that the format of "CDAT", and the fact that generation > is represented as higher 30-bit of a be32 integer, is very much > hardcoded in the design and is hard to change, but your new version > of graph file can be designed not to use "CDAT" chunk at all, and > instead have the commit data with new version of generation numbers > stored in a different chunk (say "CDA2") to force older version of > Git not to use the new graph file---would that work? A commit-graph without "CDAT" chunk will hard fail on older versions of Git. verify_commit_graph_lite() errors out if chunk_commit_data is null. Metadata chunk seems the way to go. Regards Abhishek
