diff options
author | Derrick Stolee <dstolee@microsoft.com> | 2019-10-24 13:40:41 +0000 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2019-10-25 11:19:14 +0900 |
commit | e88aab917e0dc3e99af8fb0f3ecbef66ac3e49b6 (patch) | |
tree | ae998fc04a1933a947cdeeb92dcb70c7da6ff7f4 /Documentation/RelNotes/2.19.2.txt | |
parent | fetch: add fetch.writeCommitGraph config setting (diff) | |
download | tgif-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.19.2.txt')
0 files changed, 0 insertions, 0 deletions