[PATCH v4 0/2] [v2.24.0-rc0 BUG] fetch.writeCommitGraph fails on first fetch

["Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com>]

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'.
      
          Helped-by: Jeff King <peff@peff.net>
          Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
     @@ -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