summaryrefslogtreecommitdiff
path: root/t/t5515/refs.br-config-explicit-merge
diff options
context:
space:
mode:
authorLibravatar SZEDER Gábor <szeder.dev@gmail.com>2018-10-11 11:53:57 +0200
committerLibravatar Junio C Hamano <gitster@pobox.com>2018-10-12 07:23:29 +0900
commit4c490f3d321da415b8d3bec4a04565906657b9c9 (patch)
tree7edae412d7a71f336293e5cdee3c13d9c6be28b3 /t/t5515/refs.br-config-explicit-merge
parentsplit-index: smudge and add racily clean cache entries to split index (diff)
downloadtgif-4c490f3d321da415b8d3bec4a04565906657b9c9.tar.xz
split-index: BUG() when cache entry refers to non-existing shared entry
When the split index feature is in use, then a cache entry is: - either only present in the split index, in which case its 'index' field must be 0, - or it should refer to an existing entry in the shared index, i.e. the 'index' field can't be greater than the size of the shared index. If a cache entry were to refer to a non-existing entry in the shared index, then that's a sign of something being wrong in the index state, either as a result of a bug in dealing with the split/shared index entries, or perhaps a (potentially unrelated) memory corruption issue. prepare_to_write_split_index() already has a condition to catch cache entries with such bogus 'index' field, but instead of calling BUG() it just sets cache entry's 'index = 0', and the entry will then be written to the new split index. Don't write a new index file from bogus index state, and call BUG() upon encountering an cache entry referring to a non-existing shared index entry. Running the test suite repeatedly with 'GIT_TEST_SPLIT_INDEX=yes' doesn't trigger this condition. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t5515/refs.br-config-explicit-merge')
0 files changed, 0 insertions, 0 deletions