Hi Jakub, On Tue, Sep 15, 2020 at 09:05:18PM +0200, Jakub Narębski wrote: > I'd like to point out that latest series of patches by Abhishek Kumar > which are final part of 'Implement Generation Number v2' is at what I > believe is next to final iteration: > > "[PATCH v3 00/11] [GSoC] Implement Corrected Commit Date" > https://lore.kernel.org/git/pull.676.v3.git.1597509583.gitgitgadget@xxxxxxxxx/T/#u > > It is waiting for the decision on *how to implement storing* new > generation number in the commit-graph file: should we store corrected > commit date directly as 64 bit value, or should we store corrected > commit date offset as 32 bit value with overflow handling? > > Switching from 64 bits to 32 bits halves the size of the GDAT > (Generation DATa) chunk, but decreases the size of the commit-graph file > by at most 7%. For large repository, like MS Windows with 3M commits in > 2019 it would mean decreasing the size of the commit-graph file by > 11.8 MiB (if I calculated it correctly). > > Because corrected commit date offsets are not monotone, that is after > value that doesn't fit in 32 bits (in parent) there can be one that does > (in child). It is extremely unlikely that in real repositories there > would be that large corrections needed, but it can happen in theory, and > therfore we need some way to handle overflow if we choose this option. > And of course we should test that overflow handling works correctly. > > So there is tradeoff between complexity and commit-graph file size. If you think that not being able to fit into 32 bits is unlikely, then I don't think it makes sense to store those same values inside of 64 bits, either. Of course, that means implementing overflow detection, but that's a small price to pay for shaving off extra data from the commit-graph file. > Best, > -- > Jakub Narębski Thanks, Taylor
