Re: [PATCH v3 3/5] commit-graph: fix ordering bug in generation numbers

> From: Derrick Stolee <derrickstolee@github.com>
>
> 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.

> 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@gmail.com>