[PATCH v2 0/4] Commit-graph: Generation Number v2 Fixes

This patch series fixes some bugs in generation number v2. They were discovered while building generation number v3, but that implementation will be delayed until these fixes are merged.

In particular, Git has been ignoring corrected commit dates since shortly after they were introduced. This is due to a bug I introduced when trying to make split commit-graphs safer with mixed generation number versions. I also noticed an issue with the offset overflows that I only noticed after writing generation number v3 using a smaller offset size, actually triggering the bug in the test suite.

Updates in v2 =============

 * Dropped generation v3 patches, saving them for later.
 * Updated a commit message to more clearly describe the problem with the
   old code.
 * Used an || instead of two if statements in test script.

Thanks, -Stolee

Derrick Stolee (4):
  test-read-graph: include extra post-parse info
  commit-graph: fix ordering bug in generation numbers
  commit-graph: start parsing generation v2 (again)
  commit-graph: fix generation number v2 overflow values

 commit-graph.c                | 15 +++++++++++----
 t/helper/test-read-graph.c    | 13 +++++++++++++
 t/t4216-log-bloom.sh          |  1 +
 t/t5318-commit-graph.sh       | 34 +++++++++++++++++++++++++++++-----
 t/t5324-split-commit-graph.sh | 10 ++++++++++
 5 files changed, 64 insertions(+), 9 deletions(-)

base-commit: dab1b7905d0b295f1acef9785bb2b9cbb0fdec84
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1163%2Fderrickstolee%2Fgen-v3-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1163/derrickstolee/gen-v3-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/1163

Range-diff vs v1:

 1:  2f89275314b = 1:  2f89275314b test-read-graph: include extra post-parse info
 2:  6e47ffed257 ! 2:  cbcbf10e699 commit-graph: fix ordering bug in generation numbers
     @@ Commit message
          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.
     +    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
     -    here, because we might start double-counting commits that are computed
     -    because of the depth-first search walk from a commit with an earlier
     -    OID.
     +    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.
 3:  a3436b92a32 = 3:  5bc6a7660d8 commit-graph: start parsing generation v2 (again)
 4:  de7ab2f39d9 ! 4:  193217c71e0 commit-graph: fix generation number v2 overflow values
     @@ t/t5318-commit-graph.sh: test_expect_success 'corrupt commit-graph write (missin
      +# 32-bits. The graph_git_behavior checks can't take a
      +# prereq, so just stop here if we are on a 32-bit machine.
      +
     -+if ! test_have_prereq TIME_IS_64BIT
     -+then
     -+	test_done
     -+fi
     -+if ! test_have_prereq TIME_T_IS_64BIT
     ++if ! test_have_prereq TIME_IS_64BIT || ! test_have_prereq TIME_T_IS_64BIT
      +then
      +	test_done
      +fi
 5:  7f9b65bd225 < -:  ----------- commit-graph: document file format v2
 6:  28fe8824ba7 < -:  ----------- commit-graph: parse file format v2
 7:  ade697c4d34 < -:  ----------- commit-graph: write file format v2