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. 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?
