Subject: [PATCH 0/1] [v2.24.0-rc0 BUG] fetch.writeCommitGraph fails on first fetch

From: "Derrick Stolee via GitGitGadget" <[email-masked]>
Date: Tue, 22 Oct 2019 17:28:54 +0000

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 [email-masked], [email-masked]

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