"Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > From: Derrick Stolee <derrickstolee@xxxxxxxxxx> > > When computing the generation numbers for a commit-graph, we compute > the corrected commit dates and then check if their offsets from the > actual dates is too large to fit in the 32-bit Generation Data chunk. > However, there is a problem with this approach: if we have parsed the > generation data from the previous commit-graph, then we continue the > loop because the corrected commit date is already computed. This causes > an under-count in the number of overflow values. > > It is incorrect to add an increment to num_generation_data_overflows > next to this 'continue' statement, because we might start > double-counting commits that are computed because of the depth-first > search walk from a commit with an earlier OID. > > Instead, iterate over the full commit list at the end, checking the > offsets to see how many grow beyond the maximum value. OK. > Create a new t5328-commit-graph-64-bit-time.sh test script to handle > special cases of testing 64-bit timestampes. This helps demonstrate this > bug in more cases. It still won't hit all potential cases until the next > change, which reenables reading generation numbers. Use the skip_all > trick from 0a2bfccb9c8 (t0051: use "skip_all" under !MINGW in > single-test file, 2022-02-04) to make the output clean when run on a > 32-bit system. > > Hepled-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> I can typofix this one locally if needed.
