]> git.ipfire.org Git - thirdparty/git.git/commit
t5510-fetch.sh: demonstrate fetch.writeCommitGraph bug
authorDerrick Stolee <dstolee@microsoft.com>
Thu, 24 Oct 2019 13:40:41 +0000 (13:40 +0000)
committerJunio C Hamano <gitster@pobox.com>
Fri, 25 Oct 2019 02:19:14 +0000 (11:19 +0900)
commite88aab917e0dc3e99af8fb0f3ecbef66ac3e49b6
treeae998fc04a1933a947cdeeb92dcb70c7da6ff7f4
parent50f26bd035816c2bb79582b834d59b49292502a9
t5510-fetch.sh: demonstrate fetch.writeCommitGraph bug

While dogfooding, Johannes found a bug in the fetch.writeCommitGraph
config behavior. His example initially happened during a clone with
--recurse-submodules, we found that this happens with the first fetch
after cloning a repository that contains a submodule:

$ 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.

A follow-up will fix the bug, but first we create a test that
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>
Helped-by: Szeder Gábor <szeder.dev@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t5510-fetch.sh