2014-02-23 21:49:57 +01:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='index file specific tests'
|
|
|
|
|
|
2021-10-31 00:24:13 +02:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2014-02-23 21:49:57 +01:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
2021-08-26 23:00:01 +02:00
|
|
|
sane_unset GIT_TEST_SPLIT_INDEX
|
|
|
|
|
|
2014-02-23 21:49:57 +01:00
|
|
|
test_expect_success 'setup' '
|
|
|
|
|
echo 1 >a
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'bogus GIT_INDEX_VERSION issues warning' '
|
|
|
|
|
(
|
|
|
|
|
rm -f .git/index &&
|
|
|
|
|
GIT_INDEX_VERSION=2bogus &&
|
|
|
|
|
export GIT_INDEX_VERSION &&
|
2021-08-26 23:00:00 +02:00
|
|
|
git add a 2>err &&
|
|
|
|
|
sed "s/[0-9]//" err >actual.err &&
|
2014-02-23 21:49:57 +01:00
|
|
|
sed -e "s/ Z$/ /" <<-\EOF >expect.err &&
|
|
|
|
|
warning: GIT_INDEX_VERSION set, but the value is invalid.
|
|
|
|
|
Using version Z
|
|
|
|
|
EOF
|
2021-02-11 02:53:53 +01:00
|
|
|
test_cmp expect.err actual.err
|
2014-02-23 21:49:57 +01:00
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'out of bounds GIT_INDEX_VERSION issues warning' '
|
|
|
|
|
(
|
|
|
|
|
rm -f .git/index &&
|
|
|
|
|
GIT_INDEX_VERSION=1 &&
|
|
|
|
|
export GIT_INDEX_VERSION &&
|
2021-08-26 23:00:00 +02:00
|
|
|
git add a 2>err &&
|
|
|
|
|
sed "s/[0-9]//" err >actual.err &&
|
2014-02-23 21:49:57 +01:00
|
|
|
sed -e "s/ Z$/ /" <<-\EOF >expect.err &&
|
|
|
|
|
warning: GIT_INDEX_VERSION set, but the value is invalid.
|
|
|
|
|
Using version Z
|
|
|
|
|
EOF
|
2021-02-11 02:53:53 +01:00
|
|
|
test_cmp expect.err actual.err
|
2014-02-23 21:49:57 +01:00
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'no warning with bogus GIT_INDEX_VERSION and existing index' '
|
|
|
|
|
(
|
|
|
|
|
GIT_INDEX_VERSION=1 &&
|
|
|
|
|
export GIT_INDEX_VERSION &&
|
|
|
|
|
git add a 2>actual.err &&
|
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'
Using 'test_must_be_empty' is shorter and more idiomatic than
>empty &&
test_cmp empty out
as it saves the creation of an empty file. Furthermore, sometimes the
expected empty file doesn't have such a descriptive name like 'empty',
and its creation is far away from the place where it's finally used
for comparison (e.g. in 't7600-merge.sh', where two expected empty
files are created in the 'setup' test, but are used only about 500
lines later).
These cases were found by instrumenting 'test_cmp' to error out the
test script when it's used to compare empty files, and then converted
manually.
Note that even after this patch there still remain a lot of cases
where we use 'test_cmp' to check empty files:
- Sometimes the expected output is not hard-coded in the test, but
'test_cmp' is used to ensure that two similar git commands produce
the same output, and that output happens to be empty, e.g. the
test 'submodule update --merge - ignores --merge for new
submodules' in 't7406-submodule-update.sh'.
- Repetitive common tasks, including preparing the expected results
and running 'test_cmp', are often extracted into a helper
function, and some of this helper's callsites expect no output.
- For the same reason as above, the whole 'test_expect_success'
block is within a helper function, e.g. in 't3070-wildmatch.sh'.
- Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update
(-p)' in 't9400-git-cvsserver-server.sh'.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 23:57:25 +02:00
|
|
|
test_must_be_empty actual.err
|
2014-02-23 21:49:57 +01:00
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2014-02-23 21:49:59 +01:00
|
|
|
test_expect_success 'out of bounds index.version issues warning' '
|
|
|
|
|
(
|
|
|
|
|
sane_unset GIT_INDEX_VERSION &&
|
|
|
|
|
rm -f .git/index &&
|
|
|
|
|
git config --add index.version 1 &&
|
2021-08-26 23:00:00 +02:00
|
|
|
git add a 2>err &&
|
|
|
|
|
sed "s/[0-9]//" err >actual.err &&
|
2014-02-23 21:49:59 +01:00
|
|
|
sed -e "s/ Z$/ /" <<-\EOF >expect.err &&
|
|
|
|
|
warning: index.version set, but the value is invalid.
|
|
|
|
|
Using version Z
|
|
|
|
|
EOF
|
2021-02-11 02:53:53 +01:00
|
|
|
test_cmp expect.err actual.err
|
2014-02-23 21:49:59 +01:00
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
read-cache: add index.skipHash config option
The previous change allowed skipping the hashing portion of the
hashwrite API, using it instead as a buffered write API. Disabling the
hashwrite can be particularly helpful when the write operation is in a
critical path.
One such critical path is the writing of the index. This operation is so
critical that the sparse index was created specifically to reduce the
size of the index to make these writes (and reads) faster.
This trade-off between file stability at rest and write-time performance
is not easy to balance. The index is an interesting case for a couple
reasons:
1. Writes block users. Writing the index takes place in many user-
blocking foreground operations. The speed improvement directly
impacts their use. Other file formats are typically written in the
background (commit-graph, multi-pack-index) or are super-critical to
correctness (pack-files).
2. Index files are short lived. It is rare that a user leaves an index
for a long time with many staged changes. Outside of staged changes,
the index can be completely destroyed and rewritten with minimal
impact to the user.
Following a similar approach to one used in the microsoft/git fork [1],
add a new config option (index.skipHash) that allows disabling this
hashing during the index write. The cost is that we can no longer
validate the contents for corruption-at-rest using the trailing hash.
[1] https://github.com/microsoft/git/commit/21fed2d91410f45d85279467f21d717a2db45201
We load this config from the repository config given by istate->repo,
with a fallback to the_repository if it is not set.
While older Git versions will not recognize the null hash as a special
case, the file format itself is still being met in terms of its
structure. Using this null hash will still allow Git operations to
function across older versions.
The one exception is 'git fsck' which checks the hash of the index file.
This used to be a check on every index read, but was split out to just
the index in a33fc72fe91 (read-cache: force_verify_index_checksum,
2017-04-14) and released first in Git 2.13.0. Document the versions that
relaxed these restrictions, with the optimistic expectation that this
change will be included in Git 2.40.0.
Here, we disable this check if the trailing hash is all zeroes. We add a
warning to the config option that this may cause undesirable behavior
with older Git versions.
As a quick comparison, I tested 'git update-index --force-write' with
and without index.skipHash=true on a copy of the Linux kernel
repository.
Benchmark 1: with hash
Time (mean ± σ): 46.3 ms ± 13.8 ms [User: 34.3 ms, System: 11.9 ms]
Range (min … max): 34.3 ms … 79.1 ms 82 runs
Benchmark 2: without hash
Time (mean ± σ): 26.0 ms ± 7.9 ms [User: 11.8 ms, System: 14.2 ms]
Range (min … max): 16.3 ms … 42.0 ms 69 runs
Summary
'without hash' ran
1.78 ± 0.76 times faster than 'with hash'
These performance benefits are substantial enough to allow users the
ability to opt-in to this feature, even with the potential confusion
with older 'git fsck' versions.
Test this new config option, both at a command-line level and within a
submodule. The confirmation is currently limited to confirm that 'git
fsck' does not complain about the index. Future updates will make this
test more robust.
It is critical that this test is placed before the test_index_version
tests, since those tests obliterate the .git/config file and hence lose
the setting from GIT_TEST_DEFAULT_HASH, if set.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-01-06 17:31:54 +01:00
|
|
|
test_expect_success 'index.skipHash config option' '
|
|
|
|
|
rm -f .git/index &&
|
|
|
|
|
git -c index.skipHash=true add a &&
|
2023-01-06 17:31:55 +01:00
|
|
|
test_trailing_hash .git/index >hash &&
|
|
|
|
|
echo $(test_oid zero) >expect &&
|
|
|
|
|
test_cmp expect hash &&
|
read-cache: add index.skipHash config option
The previous change allowed skipping the hashing portion of the
hashwrite API, using it instead as a buffered write API. Disabling the
hashwrite can be particularly helpful when the write operation is in a
critical path.
One such critical path is the writing of the index. This operation is so
critical that the sparse index was created specifically to reduce the
size of the index to make these writes (and reads) faster.
This trade-off between file stability at rest and write-time performance
is not easy to balance. The index is an interesting case for a couple
reasons:
1. Writes block users. Writing the index takes place in many user-
blocking foreground operations. The speed improvement directly
impacts their use. Other file formats are typically written in the
background (commit-graph, multi-pack-index) or are super-critical to
correctness (pack-files).
2. Index files are short lived. It is rare that a user leaves an index
for a long time with many staged changes. Outside of staged changes,
the index can be completely destroyed and rewritten with minimal
impact to the user.
Following a similar approach to one used in the microsoft/git fork [1],
add a new config option (index.skipHash) that allows disabling this
hashing during the index write. The cost is that we can no longer
validate the contents for corruption-at-rest using the trailing hash.
[1] https://github.com/microsoft/git/commit/21fed2d91410f45d85279467f21d717a2db45201
We load this config from the repository config given by istate->repo,
with a fallback to the_repository if it is not set.
While older Git versions will not recognize the null hash as a special
case, the file format itself is still being met in terms of its
structure. Using this null hash will still allow Git operations to
function across older versions.
The one exception is 'git fsck' which checks the hash of the index file.
This used to be a check on every index read, but was split out to just
the index in a33fc72fe91 (read-cache: force_verify_index_checksum,
2017-04-14) and released first in Git 2.13.0. Document the versions that
relaxed these restrictions, with the optimistic expectation that this
change will be included in Git 2.40.0.
Here, we disable this check if the trailing hash is all zeroes. We add a
warning to the config option that this may cause undesirable behavior
with older Git versions.
As a quick comparison, I tested 'git update-index --force-write' with
and without index.skipHash=true on a copy of the Linux kernel
repository.
Benchmark 1: with hash
Time (mean ± σ): 46.3 ms ± 13.8 ms [User: 34.3 ms, System: 11.9 ms]
Range (min … max): 34.3 ms … 79.1 ms 82 runs
Benchmark 2: without hash
Time (mean ± σ): 26.0 ms ± 7.9 ms [User: 11.8 ms, System: 14.2 ms]
Range (min … max): 16.3 ms … 42.0 ms 69 runs
Summary
'without hash' ran
1.78 ± 0.76 times faster than 'with hash'
These performance benefits are substantial enough to allow users the
ability to opt-in to this feature, even with the potential confusion
with older 'git fsck' versions.
Test this new config option, both at a command-line level and within a
submodule. The confirmation is currently limited to confirm that 'git
fsck' does not complain about the index. Future updates will make this
test more robust.
It is critical that this test is placed before the test_index_version
tests, since those tests obliterate the .git/config file and hence lose
the setting from GIT_TEST_DEFAULT_HASH, if set.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-01-06 17:31:54 +01:00
|
|
|
git fsck &&
|
|
|
|
|
|
2023-01-06 17:31:56 +01:00
|
|
|
rm -f .git/index &&
|
|
|
|
|
git -c feature.manyFiles=true add a &&
|
|
|
|
|
test_trailing_hash .git/index >hash &&
|
|
|
|
|
cmp expect hash &&
|
|
|
|
|
|
|
|
|
|
rm -f .git/index &&
|
|
|
|
|
git -c feature.manyFiles=true \
|
|
|
|
|
-c index.skipHash=false add a &&
|
|
|
|
|
test_trailing_hash .git/index >hash &&
|
|
|
|
|
! cmp expect hash &&
|
|
|
|
|
|
read-cache: add index.skipHash config option
The previous change allowed skipping the hashing portion of the
hashwrite API, using it instead as a buffered write API. Disabling the
hashwrite can be particularly helpful when the write operation is in a
critical path.
One such critical path is the writing of the index. This operation is so
critical that the sparse index was created specifically to reduce the
size of the index to make these writes (and reads) faster.
This trade-off between file stability at rest and write-time performance
is not easy to balance. The index is an interesting case for a couple
reasons:
1. Writes block users. Writing the index takes place in many user-
blocking foreground operations. The speed improvement directly
impacts their use. Other file formats are typically written in the
background (commit-graph, multi-pack-index) or are super-critical to
correctness (pack-files).
2. Index files are short lived. It is rare that a user leaves an index
for a long time with many staged changes. Outside of staged changes,
the index can be completely destroyed and rewritten with minimal
impact to the user.
Following a similar approach to one used in the microsoft/git fork [1],
add a new config option (index.skipHash) that allows disabling this
hashing during the index write. The cost is that we can no longer
validate the contents for corruption-at-rest using the trailing hash.
[1] https://github.com/microsoft/git/commit/21fed2d91410f45d85279467f21d717a2db45201
We load this config from the repository config given by istate->repo,
with a fallback to the_repository if it is not set.
While older Git versions will not recognize the null hash as a special
case, the file format itself is still being met in terms of its
structure. Using this null hash will still allow Git operations to
function across older versions.
The one exception is 'git fsck' which checks the hash of the index file.
This used to be a check on every index read, but was split out to just
the index in a33fc72fe91 (read-cache: force_verify_index_checksum,
2017-04-14) and released first in Git 2.13.0. Document the versions that
relaxed these restrictions, with the optimistic expectation that this
change will be included in Git 2.40.0.
Here, we disable this check if the trailing hash is all zeroes. We add a
warning to the config option that this may cause undesirable behavior
with older Git versions.
As a quick comparison, I tested 'git update-index --force-write' with
and without index.skipHash=true on a copy of the Linux kernel
repository.
Benchmark 1: with hash
Time (mean ± σ): 46.3 ms ± 13.8 ms [User: 34.3 ms, System: 11.9 ms]
Range (min … max): 34.3 ms … 79.1 ms 82 runs
Benchmark 2: without hash
Time (mean ± σ): 26.0 ms ± 7.9 ms [User: 11.8 ms, System: 14.2 ms]
Range (min … max): 16.3 ms … 42.0 ms 69 runs
Summary
'without hash' ran
1.78 ± 0.76 times faster than 'with hash'
These performance benefits are substantial enough to allow users the
ability to opt-in to this feature, even with the potential confusion
with older 'git fsck' versions.
Test this new config option, both at a command-line level and within a
submodule. The confirmation is currently limited to confirm that 'git
fsck' does not complain about the index. Future updates will make this
test more robust.
It is critical that this test is placed before the test_index_version
tests, since those tests obliterate the .git/config file and hence lose
the setting from GIT_TEST_DEFAULT_HASH, if set.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-01-06 17:31:54 +01:00
|
|
|
test_commit start &&
|
|
|
|
|
git -c protocol.file.allow=always submodule add ./ sub &&
|
|
|
|
|
git config index.skipHash false &&
|
|
|
|
|
git -C sub config index.skipHash true &&
|
2023-01-17 15:49:27 +01:00
|
|
|
rm -f .git/modules/sub/index &&
|
read-cache: add index.skipHash config option
The previous change allowed skipping the hashing portion of the
hashwrite API, using it instead as a buffered write API. Disabling the
hashwrite can be particularly helpful when the write operation is in a
critical path.
One such critical path is the writing of the index. This operation is so
critical that the sparse index was created specifically to reduce the
size of the index to make these writes (and reads) faster.
This trade-off between file stability at rest and write-time performance
is not easy to balance. The index is an interesting case for a couple
reasons:
1. Writes block users. Writing the index takes place in many user-
blocking foreground operations. The speed improvement directly
impacts their use. Other file formats are typically written in the
background (commit-graph, multi-pack-index) or are super-critical to
correctness (pack-files).
2. Index files are short lived. It is rare that a user leaves an index
for a long time with many staged changes. Outside of staged changes,
the index can be completely destroyed and rewritten with minimal
impact to the user.
Following a similar approach to one used in the microsoft/git fork [1],
add a new config option (index.skipHash) that allows disabling this
hashing during the index write. The cost is that we can no longer
validate the contents for corruption-at-rest using the trailing hash.
[1] https://github.com/microsoft/git/commit/21fed2d91410f45d85279467f21d717a2db45201
We load this config from the repository config given by istate->repo,
with a fallback to the_repository if it is not set.
While older Git versions will not recognize the null hash as a special
case, the file format itself is still being met in terms of its
structure. Using this null hash will still allow Git operations to
function across older versions.
The one exception is 'git fsck' which checks the hash of the index file.
This used to be a check on every index read, but was split out to just
the index in a33fc72fe91 (read-cache: force_verify_index_checksum,
2017-04-14) and released first in Git 2.13.0. Document the versions that
relaxed these restrictions, with the optimistic expectation that this
change will be included in Git 2.40.0.
Here, we disable this check if the trailing hash is all zeroes. We add a
warning to the config option that this may cause undesirable behavior
with older Git versions.
As a quick comparison, I tested 'git update-index --force-write' with
and without index.skipHash=true on a copy of the Linux kernel
repository.
Benchmark 1: with hash
Time (mean ± σ): 46.3 ms ± 13.8 ms [User: 34.3 ms, System: 11.9 ms]
Range (min … max): 34.3 ms … 79.1 ms 82 runs
Benchmark 2: without hash
Time (mean ± σ): 26.0 ms ± 7.9 ms [User: 11.8 ms, System: 14.2 ms]
Range (min … max): 16.3 ms … 42.0 ms 69 runs
Summary
'without hash' ran
1.78 ± 0.76 times faster than 'with hash'
These performance benefits are substantial enough to allow users the
ability to opt-in to this feature, even with the potential confusion
with older 'git fsck' versions.
Test this new config option, both at a command-line level and within a
submodule. The confirmation is currently limited to confirm that 'git
fsck' does not complain about the index. Future updates will make this
test more robust.
It is critical that this test is placed before the test_index_version
tests, since those tests obliterate the .git/config file and hence lose
the setting from GIT_TEST_DEFAULT_HASH, if set.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-01-06 17:31:54 +01:00
|
|
|
>sub/file &&
|
|
|
|
|
git -C sub add a &&
|
2023-01-06 17:31:55 +01:00
|
|
|
test_trailing_hash .git/modules/sub/index >hash &&
|
|
|
|
|
test_cmp expect hash &&
|
read-cache: add index.skipHash config option
The previous change allowed skipping the hashing portion of the
hashwrite API, using it instead as a buffered write API. Disabling the
hashwrite can be particularly helpful when the write operation is in a
critical path.
One such critical path is the writing of the index. This operation is so
critical that the sparse index was created specifically to reduce the
size of the index to make these writes (and reads) faster.
This trade-off between file stability at rest and write-time performance
is not easy to balance. The index is an interesting case for a couple
reasons:
1. Writes block users. Writing the index takes place in many user-
blocking foreground operations. The speed improvement directly
impacts their use. Other file formats are typically written in the
background (commit-graph, multi-pack-index) or are super-critical to
correctness (pack-files).
2. Index files are short lived. It is rare that a user leaves an index
for a long time with many staged changes. Outside of staged changes,
the index can be completely destroyed and rewritten with minimal
impact to the user.
Following a similar approach to one used in the microsoft/git fork [1],
add a new config option (index.skipHash) that allows disabling this
hashing during the index write. The cost is that we can no longer
validate the contents for corruption-at-rest using the trailing hash.
[1] https://github.com/microsoft/git/commit/21fed2d91410f45d85279467f21d717a2db45201
We load this config from the repository config given by istate->repo,
with a fallback to the_repository if it is not set.
While older Git versions will not recognize the null hash as a special
case, the file format itself is still being met in terms of its
structure. Using this null hash will still allow Git operations to
function across older versions.
The one exception is 'git fsck' which checks the hash of the index file.
This used to be a check on every index read, but was split out to just
the index in a33fc72fe91 (read-cache: force_verify_index_checksum,
2017-04-14) and released first in Git 2.13.0. Document the versions that
relaxed these restrictions, with the optimistic expectation that this
change will be included in Git 2.40.0.
Here, we disable this check if the trailing hash is all zeroes. We add a
warning to the config option that this may cause undesirable behavior
with older Git versions.
As a quick comparison, I tested 'git update-index --force-write' with
and without index.skipHash=true on a copy of the Linux kernel
repository.
Benchmark 1: with hash
Time (mean ± σ): 46.3 ms ± 13.8 ms [User: 34.3 ms, System: 11.9 ms]
Range (min … max): 34.3 ms … 79.1 ms 82 runs
Benchmark 2: without hash
Time (mean ± σ): 26.0 ms ± 7.9 ms [User: 11.8 ms, System: 14.2 ms]
Range (min … max): 16.3 ms … 42.0 ms 69 runs
Summary
'without hash' ran
1.78 ± 0.76 times faster than 'with hash'
These performance benefits are substantial enough to allow users the
ability to opt-in to this feature, even with the potential confusion
with older 'git fsck' versions.
Test this new config option, both at a command-line level and within a
submodule. The confirmation is currently limited to confirm that 'git
fsck' does not complain about the index. Future updates will make this
test more robust.
It is critical that this test is placed before the test_index_version
tests, since those tests obliterate the .git/config file and hence lose
the setting from GIT_TEST_DEFAULT_HASH, if set.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-01-06 17:31:54 +01:00
|
|
|
git -C sub fsck
|
|
|
|
|
'
|
|
|
|
|
|
2019-08-13 20:37:47 +02:00
|
|
|
test_index_version () {
|
|
|
|
|
INDEX_VERSION_CONFIG=$1 &&
|
|
|
|
|
FEATURE_MANY_FILES=$2 &&
|
|
|
|
|
ENV_VAR_VERSION=$3
|
|
|
|
|
EXPECTED_OUTPUT_VERSION=$4 &&
|
2014-02-23 21:49:59 +01:00
|
|
|
(
|
|
|
|
|
rm -f .git/index &&
|
2019-08-13 20:37:47 +02:00
|
|
|
rm -f .git/config &&
|
|
|
|
|
if test "$INDEX_VERSION_CONFIG" -ne 0
|
|
|
|
|
then
|
|
|
|
|
git config --add index.version $INDEX_VERSION_CONFIG
|
|
|
|
|
fi &&
|
|
|
|
|
git config --add feature.manyFiles $FEATURE_MANY_FILES
|
|
|
|
|
if test "$ENV_VAR_VERSION" -ne 0
|
|
|
|
|
then
|
|
|
|
|
GIT_INDEX_VERSION=$ENV_VAR_VERSION &&
|
|
|
|
|
export GIT_INDEX_VERSION
|
|
|
|
|
else
|
|
|
|
|
unset GIT_INDEX_VERSION
|
|
|
|
|
fi &&
|
2021-08-26 22:59:59 +02:00
|
|
|
git add a &&
|
2019-08-13 20:37:47 +02:00
|
|
|
echo $EXPECTED_OUTPUT_VERSION >expect &&
|
2018-03-24 08:44:44 +01:00
|
|
|
test-tool index-version <.git/index >actual &&
|
2014-02-23 21:49:59 +01:00
|
|
|
test_cmp expect actual
|
|
|
|
|
)
|
2019-08-13 20:37:47 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test_expect_success 'index version config precedence' '
|
2019-10-23 22:38:57 +02:00
|
|
|
test_index_version 0 false 0 2 &&
|
|
|
|
|
test_index_version 2 false 0 2 &&
|
|
|
|
|
test_index_version 3 false 0 2 &&
|
|
|
|
|
test_index_version 4 false 0 4 &&
|
2019-08-13 20:37:47 +02:00
|
|
|
test_index_version 2 false 4 4 &&
|
|
|
|
|
test_index_version 2 true 0 2 &&
|
|
|
|
|
test_index_version 0 true 0 4 &&
|
|
|
|
|
test_index_version 0 true 2 2
|
2014-02-23 21:49:59 +01:00
|
|
|
'
|
|
|
|
|
|
2014-02-23 21:49:57 +01:00
|
|
|
test_done
|