fetch.writeCommitGraph fails on first fetch

UPDATE for V2: We now know the full repro, and a test is added. Thanks Szeder and Peff for your insights!

UPDATE in V3: Cleaned up the commit messages and some test details.

UPDATE in V4: There is an unfortunate interaction with GIT_TEST_COMMIT_GRAPH that requires an update to the test. Sorry for not noticing this earlier. Thanks, Johannes for pointing it out!

While dogfooding, Johannes found a bug in the fetch.writeCommitGraph config behavior. While his example initially happened during a clone with --recurse-submodules, (UPDATE) and the submodule is important, but --recurse-submodules is not:

$ git clone <url> test
$ cd test
$ git -c fetch.writeCommitGraph=true fetch origin
Computing commit graph generation numbers: 100% (12/12), done.
BUG: commit-graph.c:886: missing parent <hash1> for commit <hash2>
Aborted (core dumped)

In the repo I had cloned, there were really 60 commits to scan, but only 12 were in the list to write when calling compute_generation_numbers(). A commit in the list expects to see a parent, but that parent is not in the list. The simple example I used for my testing was
https://github.com/derrickstolee/numbers. Thie repo HAS A SUBMODULE, I just forgot. Sorry for derailing the investigation somewhat.

The details above are the start of the commit message for [PATCH 1/2], including a test that fails when fetching after cloning a repo with a submodule.

In [PATCH 2/2], I actually have the fix. I tried to include as much detail as I could for how I investigated the problem and why I think this is the right solution. I added details that have come from the on-list discussion, including what the submodule code is doing and why REACHABLE is no longer used in commit-reach.c.

Thanks, -Stolee

Derrick Stolee (2):
t5510-fetch.sh: demonstrate fetch.writeCommitGraph bug
commit-graph: fix writing first commit-graph during fetch

 commit-graph.c   | 11 +++++++----
 commit-reach.c   |  1 -
 object.h         |  3 ++-
 t/t5510-fetch.sh | 16 ++++++++++++++++
 4 files changed, 25 insertions(+), 6 deletions(-)

base-commit: d966095db01190a2196e31195ea6fa0c722aa732
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-415%2Fderrickstolee%2Ffetch-first-write-fail-v4
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-415/derrickstolee/fetch-first-write-fail-v4
Pull-Request: https://github.com/gitgitgadget/git/pull/415

Range-diff vs v3:

1: ce53b5a7bf ! 1: 8150108471 t5510-fetch.sh: demonstrate fetch.writeCommitGraph bug
@@ -20,7 +20,10 @@
parent, but that parent is not in the list.

A follow-up will fix the bug, but first we create a test that
- demonstrates the problem.
+ demonstrates the problem. This test must be careful about an existing
+ commit-graph file, since GIT_TEST_COMMIT_GRAPH=1 will cause the repo we
+ are cloning to already have one. This then prevents the incremtnal
+ commit-graph write during the first 'git fetch'.

@@ -44,7 +47,7 @@
+ git clone "super" super-clone &&
+ (
+ cd super-clone &&
-+ test_path_is_missing .git/objects/info/commit-graphs/commit-graph-chain &&
++ rm -rf .git/objects/info &&
+ git -c fetch.writeCommitGraph=true fetch origin &&
+ test_path_is_file .git/objects/info/commit-graphs/commit-graph-chain
+ )
2: edacfff490 = 2: 6d01e90591 commit-graph: fix writing first commit-graph during fetch

gitgitgadget