From: Junio C Hamano Date: Tue, 01 Mar 2022 20:13:21 GMT Subject: Re: [PATCH v3 3/5] commit-graph: fix ordering bug in generation numbers Message-ID: In-Reply-To: <562341b76b30ff3cdc01cea4cda550a7b8165bdd.1646164112.git.gitgitgadget@gmail.com> "Derrick Stolee via GitGitGadget" writes: > From: Derrick Stolee > > 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 I can typofix this one locally if needed.