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

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.schinde...@gmx.de, p...@peff.net

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
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git 
Pull-Request: https://github.com/gitgitgadget/git/pull/415

Reply via email to