]> git.ipfire.org Git - thirdparty/git.git/commit
sparse-index: sparse index is disallowed when split index is active
authorJohannes Schindelin <johannes.schindelin@gmx.de>
Wed, 19 Jan 2022 17:29:37 +0000 (17:29 +0000)
committerJunio C Hamano <gitster@pobox.com>
Mon, 24 Jan 2022 01:06:05 +0000 (17:06 -0800)
commitae103c37d370e5c1b0720159e9582cb56b7c53f0
tree274a1ea4ac6e2461883afc9a1ae02558bcb98282
parent297ca895a27a6bbdb7906371d533f72a12ad25b2
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>
sparse-index.c