summaryrefslogtreecommitdiff
path: root/Documentation/RelNotes/2.13.5.txt
diff options
context:
space:
mode:
authorLibravatar Derrick Stolee <dstolee@microsoft.com>2019-10-24 13:40:41 +0000
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-10-25 11:19:14 +0900
commite88aab917e0dc3e99af8fb0f3ecbef66ac3e49b6 (patch)
treeae998fc04a1933a947cdeeb92dcb70c7da6ff7f4 /Documentation/RelNotes/2.13.5.txt
parentfetch: add fetch.writeCommitGraph config setting (diff)
downloadtgif-e88aab917e0dc3e99af8fb0f3ecbef66ac3e49b6.tar.xz
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>
Diffstat (limited to 'Documentation/RelNotes/2.13.5.txt')
0 files changed, 0 insertions, 0 deletions