While dogfooding, Johannes found a bug in the fetch.writeCommitGraph config behavior. While his example initially happened during a clone with --recurse-submodules, we found that it is actually a problem with the first fetch after a new clone and no existing commit-graph file: $ 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 details above are the start of the commit message for [PATCH 1/1]. 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 would like help creating a test that demonstrates this problem. It does not appear to trigger on the simplest examples. The simple example I used for my testing was https://github.com/derrickstolee/numbers Thanks, -Stolee /cc johannes.schindelin@xxxxxx, peff@xxxxxxxx Derrick Stolee (1): commit-graph: fix writing first commit-graph during fetch commit-graph.c | 11 +++++++---- commit-reach.c | 1 - object.h | 3 ++- 3 files changed, 9 insertions(+), 6 deletions(-) base-commit: d966095db01190a2196e31195ea6fa0c722aa732 Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-415%2Fderrickstolee%2Ffetch-first-write-fail-v1 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-415/derrickstolee/fetch-first-write-fail-v1 Pull-Request: https://github.com/gitgitgadget/git/pull/415 -- gitgitgadget
