diff options
author | Johannes Schindelin <johannes.schindelin@gmx.de> | 2022-01-19 17:29:37 +0000 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2022-01-23 17:06:05 -0800 |
commit | ae103c37d370e5c1b0720159e9582cb56b7c53f0 (patch) | |
tree | 274a1ea4ac6e2461883afc9a1ae02558bcb98282 /t/t6434-merge-recursive-rename-options.sh | |
parent | Merge branch 'js/branch-track-inherit' (diff) | |
download | tgif-ae103c37d370e5c1b0720159e9582cb56b7c53f0.tar.xz |
sparse-index: sparse index is disallowed when split index is active
In 6e773527b6b (sparse-index: convert from full to sparse, 2021-03-30),
we introduced initial support for a sparse index, and were careful to
avoid converting to a sparse index in the presence of a split index.
However, when we _just_ read a freshly-initialized index, it might not
contain a split index even if _writing_ it will add one by virtue of
being asked for via the `GIT_TEST_SPLIT_INDEX` variable.
We did not notice any problems with checking _only_ for `split_index`
(and not `GIT_TEST_SPLIT_INDEX`) right until both
`vd/sparse-sparsity-fix-on-read` _and_ `vd/sparse-reset` were merged.
Those two topics' interplay triggers a bug in conjunction with running
t1091.15 when `GIT_TEST_SPLIT_INDEX=true` in the following way:
`vd/sparse-sparsity-fix-on-read` ensures that the index is made sparse
right after reading, and `vd/sparse-reset` ensures that the index is
made non-sparse again unless running in the `--soft` mode. Since the
split index feature is incompatible with the sparse index feature, we
see a symptom like this:
fatal: position for replacement 4 exceeds base index size 4
Let's fix this by avoiding the conversion to a sparse index when
`GIT_TEST_SPLIT_INDEX=true`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Reviewed-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t6434-merge-recursive-rename-options.sh')
0 files changed, 0 insertions, 0 deletions