2014-06-13 14:19:51 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='split index mode tests'
|
|
|
|
|
|
2020-11-19 00:44:21 +01:00
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
|
tests: mark tests relying on the current default for `init.defaultBranch`
In addition to the manual adjustment to let the `linux-gcc` CI job run
the test suite with `master` and then with `main`, this patch makes sure
that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts
that currently rely on the initial branch name being `master by default.
To determine which test scripts to mark up, the first step was to
force-set the default branch name to `master` in
- all test scripts that contain the keyword `master`,
- t4211, which expects `t/t4211/history.export` with a hard-coded ref to
initialize the default branch,
- t5560 because it sources `t/t556x_common` which uses `master`,
- t8002 and t8012 because both source `t/annotate-tests.sh` which also
uses `master`)
This trick was performed by this command:
$ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' $(git grep -l master t/t[0-9]*.sh) \
t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh
After that, careful, manual inspection revealed that some of the test
scripts containing the needle `master` do not actually rely on a
specific default branch name: either they mention `master` only in a
comment, or they initialize that branch specificially, or they do not
actually refer to the current default branch. Therefore, the
aforementioned modification was undone in those test scripts thusly:
$ git checkout HEAD -- \
t/t0027-auto-crlf.sh t/t0060-path-utils.sh \
t/t1011-read-tree-sparse-checkout.sh \
t/t1305-config-include.sh t/t1309-early-config.sh \
t/t1402-check-ref-format.sh t/t1450-fsck.sh \
t/t2024-checkout-dwim.sh \
t/t2106-update-index-assume-unchanged.sh \
t/t3040-subprojects-basic.sh t/t3301-notes.sh \
t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \
t/t3436-rebase-more-options.sh \
t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \
t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \
t/t5511-refspec.sh t/t5526-fetch-submodules.sh \
t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \
t/t5548-push-porcelain.sh \
t/t5552-skipping-fetch-negotiator.sh \
t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \
t/t5614-clone-submodules-shallow.sh \
t/t7508-status.sh t/t7606-merge-custom.sh \
t/t9302-fast-import-unpack-limit.sh
We excluded one set of test scripts in these commands, though: the range
of `git p4` tests. The reason? `git p4` stores the (foreign) remote
branch in the branch called `p4/master`, which is obviously not the
default branch. Manual analysis revealed that only five of these tests
actually require a specific default branch name to pass; They were
modified thusly:
$ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' t/t980[0167]*.sh t/t9811*.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 00:44:19 +01:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
|
2014-06-13 14:19:51 +02:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
# We need total control of index splitting here
|
|
|
|
|
sane_unset GIT_TEST_SPLIT_INDEX
|
2018-10-10 17:59:35 +02:00
|
|
|
|
|
|
|
|
# Testing a hard coded SHA against an index with an extension
|
|
|
|
|
# that can vary from run to run is problematic so we disable
|
|
|
|
|
# those extensions.
|
2018-09-19 01:29:35 +02:00
|
|
|
sane_unset GIT_TEST_FSMONITOR
|
2018-10-10 17:59:35 +02:00
|
|
|
sane_unset GIT_TEST_INDEX_THREADS
|
2014-06-13 14:19:51 +02:00
|
|
|
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
# Create a file named as $1 with content read from stdin.
|
|
|
|
|
# Set the file's mtime to a few seconds in the past to avoid racy situations.
|
|
|
|
|
create_non_racy_file () {
|
|
|
|
|
cat >"$1" &&
|
|
|
|
|
test-tool chmtime =-5 "$1"
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-29 00:59:27 +02:00
|
|
|
test_expect_success 'setup' '
|
|
|
|
|
test_oid_cache <<-EOF
|
|
|
|
|
own_v3 sha1:8299b0bcd1ac364e5f1d7768efb62fa2da79a339
|
|
|
|
|
own_v3 sha256:38a6d2925e3eceec33ad7b34cbff4e0086caa0daf28f31e51f5bd94b4a7af86b
|
|
|
|
|
|
|
|
|
|
base_v3 sha1:39d890139ee5356c7ef572216cebcd27aa41f9df
|
|
|
|
|
base_v3 sha256:c9baeadf905112bf6c17aefbd7d02267afd70ded613c30cafed2d40cb506e1ed
|
|
|
|
|
|
|
|
|
|
own_v4 sha1:432ef4b63f32193984f339431fd50ca796493569
|
|
|
|
|
own_v4 sha256:6738ac6319c25b694afa7bcc313deb182d1a59b68bf7a47b4296de83478c0420
|
|
|
|
|
|
|
|
|
|
base_v4 sha1:508851a7f0dfa8691e9f69c7f055865389012491
|
|
|
|
|
base_v4 sha256:3177d4adfdd4b6904f7e921d91d715a471c0dde7cf6a4bba574927f02b699508
|
|
|
|
|
EOF
|
|
|
|
|
'
|
|
|
|
|
|
2014-06-13 14:19:51 +02:00
|
|
|
test_expect_success 'enable split index' '
|
2017-02-27 19:00:08 +01:00
|
|
|
git config splitIndex.maxPercentChange 100 &&
|
2014-06-13 14:19:51 +02:00
|
|
|
git update-index --split-index &&
|
2018-03-24 08:44:40 +01:00
|
|
|
test-tool dump-split-index .git/index >actual &&
|
2018-03-24 08:44:44 +01:00
|
|
|
indexversion=$(test-tool index-version <.git/index) &&
|
2018-11-20 07:11:47 +01:00
|
|
|
|
|
|
|
|
# NEEDSWORK: Stop hard-coding checksums.
|
2015-03-20 19:20:30 +01:00
|
|
|
if test "$indexversion" = "4"
|
|
|
|
|
then
|
2019-06-29 00:59:27 +02:00
|
|
|
own=$(test_oid own_v4)
|
|
|
|
|
base=$(test_oid base_v4)
|
2015-03-20 19:20:30 +01:00
|
|
|
else
|
2019-06-29 00:59:27 +02:00
|
|
|
own=$(test_oid own_v3)
|
|
|
|
|
base=$(test_oid base_v3)
|
2015-03-20 19:20:30 +01:00
|
|
|
fi &&
|
2018-11-20 07:11:47 +01:00
|
|
|
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
own $own
|
|
|
|
|
base $base
|
|
|
|
|
replacements:
|
|
|
|
|
deletions:
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'add one file' '
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file one &&
|
2014-06-13 14:19:51 +02:00
|
|
|
git update-index --add one &&
|
|
|
|
|
git ls-files --stage >ls-files.actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >ls-files.expect <<-EOF &&
|
|
|
|
|
100644 $EMPTY_BLOB 0 one
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp ls-files.expect ls-files.actual &&
|
|
|
|
|
|
2018-03-24 08:44:40 +01:00
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
base $base
|
|
|
|
|
100644 $EMPTY_BLOB 0 one
|
|
|
|
|
replacements:
|
|
|
|
|
deletions:
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'disable split index' '
|
|
|
|
|
git update-index --no-split-index &&
|
|
|
|
|
git ls-files --stage >ls-files.actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >ls-files.expect <<-EOF &&
|
|
|
|
|
100644 $EMPTY_BLOB 0 one
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp ls-files.expect ls-files.actual &&
|
|
|
|
|
|
2018-09-06 04:48:06 +02:00
|
|
|
BASE=$(test-tool dump-split-index .git/index | sed -n "s/^own/base/p") &&
|
2018-03-24 08:44:40 +01:00
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
not a split index
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'enable split index again, "one" now belongs to base index"' '
|
|
|
|
|
git update-index --split-index &&
|
|
|
|
|
git ls-files --stage >ls-files.actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >ls-files.expect <<-EOF &&
|
|
|
|
|
100644 $EMPTY_BLOB 0 one
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp ls-files.expect ls-files.actual &&
|
|
|
|
|
|
2018-03-24 08:44:40 +01:00
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
$BASE
|
|
|
|
|
replacements:
|
|
|
|
|
deletions:
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'modify original file, base index untouched' '
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
echo modified | create_non_racy_file one &&
|
2019-06-29 00:59:27 +02:00
|
|
|
file1_blob=$(git hash-object one) &&
|
2014-06-13 14:19:51 +02:00
|
|
|
git update-index one &&
|
|
|
|
|
git ls-files --stage >ls-files.actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >ls-files.expect <<-EOF &&
|
2019-06-29 00:59:27 +02:00
|
|
|
100644 $file1_blob 0 one
|
2017-02-27 18:59:59 +01:00
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp ls-files.expect ls-files.actual &&
|
|
|
|
|
|
2018-03-24 08:44:40 +01:00
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
q_to_tab >expect <<-EOF &&
|
|
|
|
|
$BASE
|
2019-06-29 00:59:27 +02:00
|
|
|
100644 $file1_blob 0Q
|
2017-02-27 18:59:59 +01:00
|
|
|
replacements: 0
|
|
|
|
|
deletions:
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'add another file, which stays index' '
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file two &&
|
2014-06-13 14:19:51 +02:00
|
|
|
git update-index --add two &&
|
|
|
|
|
git ls-files --stage >ls-files.actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >ls-files.expect <<-EOF &&
|
2019-06-29 00:59:27 +02:00
|
|
|
100644 $file1_blob 0 one
|
2017-02-27 18:59:59 +01:00
|
|
|
100644 $EMPTY_BLOB 0 two
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp ls-files.expect ls-files.actual &&
|
|
|
|
|
|
2018-03-24 08:44:40 +01:00
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
q_to_tab >expect <<-EOF &&
|
|
|
|
|
$BASE
|
2019-06-29 00:59:27 +02:00
|
|
|
100644 $file1_blob 0Q
|
2017-02-27 18:59:59 +01:00
|
|
|
100644 $EMPTY_BLOB 0 two
|
|
|
|
|
replacements: 0
|
|
|
|
|
deletions:
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'remove file not in base index' '
|
|
|
|
|
git update-index --force-remove two &&
|
|
|
|
|
git ls-files --stage >ls-files.actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >ls-files.expect <<-EOF &&
|
2019-06-29 00:59:27 +02:00
|
|
|
100644 $file1_blob 0 one
|
2017-02-27 18:59:59 +01:00
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp ls-files.expect ls-files.actual &&
|
|
|
|
|
|
2018-03-24 08:44:40 +01:00
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
q_to_tab >expect <<-EOF &&
|
|
|
|
|
$BASE
|
2019-06-29 00:59:27 +02:00
|
|
|
100644 $file1_blob 0Q
|
2017-02-27 18:59:59 +01:00
|
|
|
replacements: 0
|
|
|
|
|
deletions:
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'remove file in base index' '
|
|
|
|
|
git update-index --force-remove one &&
|
|
|
|
|
git ls-files --stage >ls-files.actual &&
|
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 ls-files.actual &&
|
2014-06-13 14:19:51 +02:00
|
|
|
|
2018-03-24 08:44:40 +01:00
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
$BASE
|
|
|
|
|
replacements:
|
|
|
|
|
deletions: 0
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'add original file back' '
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file one &&
|
2014-06-13 14:19:51 +02:00
|
|
|
git update-index --add one &&
|
|
|
|
|
git ls-files --stage >ls-files.actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >ls-files.expect <<-EOF &&
|
|
|
|
|
100644 $EMPTY_BLOB 0 one
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp ls-files.expect ls-files.actual &&
|
|
|
|
|
|
2018-03-24 08:44:40 +01:00
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
$BASE
|
|
|
|
|
100644 $EMPTY_BLOB 0 one
|
|
|
|
|
replacements:
|
|
|
|
|
deletions: 0
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'add new file' '
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file two &&
|
2014-06-13 14:19:51 +02:00
|
|
|
git update-index --add two &&
|
|
|
|
|
git ls-files --stage >actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
100644 $EMPTY_BLOB 0 one
|
|
|
|
|
100644 $EMPTY_BLOB 0 two
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'unify index, two files remain' '
|
|
|
|
|
git update-index --no-split-index &&
|
|
|
|
|
git ls-files --stage >ls-files.actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >ls-files.expect <<-EOF &&
|
|
|
|
|
100644 $EMPTY_BLOB 0 one
|
|
|
|
|
100644 $EMPTY_BLOB 0 two
|
|
|
|
|
EOF
|
2015-03-20 11:06:15 +01:00
|
|
|
test_cmp ls-files.expect ls-files.actual &&
|
2014-06-13 14:19:51 +02:00
|
|
|
|
2018-03-24 08:44:40 +01:00
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 18:59:59 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
not a split index
|
|
|
|
|
EOF
|
2014-06-13 14:19:51 +02:00
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
rev-parse: fix several options when running in a subdirectory
In addition to making git_path() aware of certain file names that need
to be handled differently e.g. when running in worktrees, the commit
557bd833bb (git_path(): be aware of file relocation in $GIT_DIR,
2014-11-30) also snuck in a new option for `git rev-parse`:
`--git-path`.
On the face of it, there is no obvious bug in that commit's diff: it
faithfully calls git_path() on the argument and prints it out, i.e. `git
rev-parse --git-path <filename>` has the same precise behavior as
calling `git_path("<filename>")` in C.
The problem lies deeper, much deeper. In hindsight (which is always
unfair), implementing the .git/ directory discovery in
`setup_git_directory()` by changing the working directory may have
allowed us to avoid passing around a struct that contains information
about the current repository, but it bought us many, many problems.
In this case, when being called in a subdirectory, `git rev-parse`
changes the working directory to the top-level directory before calling
`git_path()`. In the new working directory, the result is correct. But
in the working directory of the calling script, it is incorrect.
Example: when calling `git rev-parse --git-path HEAD` in, say, the
Documentation/ subdirectory of Git's own source code, the string
`.git/HEAD` is printed.
Side note: that bug is hidden when running in a subdirectory of a
worktree that was added by the `git worktree` command: in that case, the
(correct) absolute path of the `HEAD` file is printed.
In the interest of time, this patch does not go the "correct" route to
introduce a struct with repository information (and removing global
state in the process), instead this patch chooses to detect when the
command was called in a subdirectory and forces the result to be an
absolute path.
While at it, we are also fixing the output of --git-common-dir and
--shared-index-path.
Lastly, please note that we reuse the same strbuf for all of the
relative_path() calls; this avoids frequent allocation (and duplicated
code), and it does not risk memory leaks, for two reasons: 1) the
cmd_rev_parse() function does not return anywhere between the use of
the new strbuf instance and its final release, and 2) git-rev-parse is
one of these "one-shot" programs in Git, i.e. it exits after running
for a very short time, meaning that all allocated memory is released
with the exit() call anyway.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-17 17:59:06 +01:00
|
|
|
test_expect_success 'rev-parse --shared-index-path' '
|
2017-02-17 17:59:02 +01:00
|
|
|
test_create_repo split-index &&
|
|
|
|
|
(
|
|
|
|
|
cd split-index &&
|
|
|
|
|
git update-index --split-index &&
|
|
|
|
|
echo .git/sharedindex* >expect &&
|
|
|
|
|
git rev-parse --shared-index-path >actual &&
|
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
mkdir subdirectory &&
|
|
|
|
|
cd subdirectory &&
|
|
|
|
|
echo ../.git/sharedindex* >expect &&
|
|
|
|
|
git rev-parse --shared-index-path >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2017-02-27 19:00:04 +01:00
|
|
|
test_expect_success 'set core.splitIndex config variable to true' '
|
|
|
|
|
git config core.splitIndex true &&
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file three &&
|
2017-02-27 19:00:04 +01:00
|
|
|
git update-index --add three &&
|
|
|
|
|
git ls-files --stage >ls-files.actual &&
|
|
|
|
|
cat >ls-files.expect <<-EOF &&
|
2019-06-29 00:59:27 +02:00
|
|
|
100644 $EMPTY_BLOB 0 one
|
|
|
|
|
100644 $EMPTY_BLOB 0 three
|
|
|
|
|
100644 $EMPTY_BLOB 0 two
|
2017-02-27 19:00:04 +01:00
|
|
|
EOF
|
|
|
|
|
test_cmp ls-files.expect ls-files.actual &&
|
2018-03-24 08:44:40 +01:00
|
|
|
BASE=$(test-tool dump-split-index .git/index | grep "^base") &&
|
|
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 19:00:04 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
$BASE
|
|
|
|
|
replacements:
|
|
|
|
|
deletions:
|
|
|
|
|
EOF
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'set core.splitIndex config variable to false' '
|
|
|
|
|
git config core.splitIndex false &&
|
|
|
|
|
git update-index --force-remove three &&
|
|
|
|
|
git ls-files --stage >ls-files.actual &&
|
|
|
|
|
cat >ls-files.expect <<-EOF &&
|
2019-06-29 00:59:27 +02:00
|
|
|
100644 $EMPTY_BLOB 0 one
|
|
|
|
|
100644 $EMPTY_BLOB 0 two
|
2017-02-27 19:00:04 +01:00
|
|
|
EOF
|
|
|
|
|
test_cmp ls-files.expect ls-files.actual &&
|
2018-03-24 08:44:40 +01:00
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 19:00:04 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
not a split index
|
|
|
|
|
EOF
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
test_expect_success 'set core.splitIndex config variable back to true' '
|
2017-02-27 19:00:09 +01:00
|
|
|
git config core.splitIndex true &&
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file three &&
|
2017-02-27 19:00:09 +01:00
|
|
|
git update-index --add three &&
|
2018-03-24 08:44:40 +01:00
|
|
|
BASE=$(test-tool dump-split-index .git/index | grep "^base") &&
|
|
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 19:00:09 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
$BASE
|
|
|
|
|
replacements:
|
|
|
|
|
deletions:
|
|
|
|
|
EOF
|
|
|
|
|
test_cmp expect actual &&
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file four &&
|
2017-02-27 19:00:09 +01:00
|
|
|
git update-index --add four &&
|
2018-03-24 08:44:40 +01:00
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 19:00:09 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
$BASE
|
2019-06-29 00:59:27 +02:00
|
|
|
100644 $EMPTY_BLOB 0 four
|
2017-02-27 19:00:09 +01:00
|
|
|
replacements:
|
|
|
|
|
deletions:
|
|
|
|
|
EOF
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'check behavior with splitIndex.maxPercentChange unset' '
|
|
|
|
|
git config --unset splitIndex.maxPercentChange &&
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file five &&
|
2017-02-27 19:00:09 +01:00
|
|
|
git update-index --add five &&
|
2018-03-24 08:44:40 +01:00
|
|
|
BASE=$(test-tool dump-split-index .git/index | grep "^base") &&
|
|
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 19:00:09 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
$BASE
|
|
|
|
|
replacements:
|
|
|
|
|
deletions:
|
|
|
|
|
EOF
|
|
|
|
|
test_cmp expect actual &&
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file six &&
|
2017-02-27 19:00:09 +01:00
|
|
|
git update-index --add six &&
|
2018-03-24 08:44:40 +01:00
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 19:00:09 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
$BASE
|
2019-06-29 00:59:27 +02:00
|
|
|
100644 $EMPTY_BLOB 0 six
|
2017-02-27 19:00:09 +01:00
|
|
|
replacements:
|
|
|
|
|
deletions:
|
|
|
|
|
EOF
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'check splitIndex.maxPercentChange set to 0' '
|
|
|
|
|
git config splitIndex.maxPercentChange 0 &&
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file seven &&
|
2017-02-27 19:00:09 +01:00
|
|
|
git update-index --add seven &&
|
2018-03-24 08:44:40 +01:00
|
|
|
BASE=$(test-tool dump-split-index .git/index | grep "^base") &&
|
|
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 19:00:09 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
$BASE
|
|
|
|
|
replacements:
|
|
|
|
|
deletions:
|
|
|
|
|
EOF
|
|
|
|
|
test_cmp expect actual &&
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file eight &&
|
2017-02-27 19:00:09 +01:00
|
|
|
git update-index --add eight &&
|
2018-03-24 08:44:40 +01:00
|
|
|
BASE=$(test-tool dump-split-index .git/index | grep "^base") &&
|
|
|
|
|
test-tool dump-split-index .git/index | sed "/^own/d" >actual &&
|
2017-02-27 19:00:09 +01:00
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
$BASE
|
|
|
|
|
replacements:
|
|
|
|
|
deletions:
|
|
|
|
|
EOF
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2017-03-06 10:41:59 +01:00
|
|
|
test_expect_success 'shared index files expire after 2 weeks by default' '
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file ten &&
|
2017-03-06 10:41:59 +01:00
|
|
|
git update-index --add ten &&
|
2017-03-06 10:42:01 +01:00
|
|
|
test $(ls .git/sharedindex.* | wc -l) -gt 2 &&
|
2017-03-06 10:41:59 +01:00
|
|
|
just_under_2_weeks_ago=$((5-14*86400)) &&
|
2018-03-24 08:44:31 +01:00
|
|
|
test-tool chmtime =$just_under_2_weeks_ago .git/sharedindex.* &&
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file eleven &&
|
2017-03-06 10:41:59 +01:00
|
|
|
git update-index --add eleven &&
|
2017-03-06 10:42:01 +01:00
|
|
|
test $(ls .git/sharedindex.* | wc -l) -gt 2 &&
|
2017-03-06 10:41:59 +01:00
|
|
|
just_over_2_weeks_ago=$((-1-14*86400)) &&
|
2018-03-24 08:44:31 +01:00
|
|
|
test-tool chmtime =$just_over_2_weeks_ago .git/sharedindex.* &&
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file twelve &&
|
2017-03-06 10:41:59 +01:00
|
|
|
git update-index --add twelve &&
|
2017-03-06 10:42:01 +01:00
|
|
|
test $(ls .git/sharedindex.* | wc -l) -le 2
|
2017-03-06 10:41:59 +01:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'check splitIndex.sharedIndexExpire set to 16 days' '
|
|
|
|
|
git config splitIndex.sharedIndexExpire "16.days.ago" &&
|
2018-03-24 08:44:31 +01:00
|
|
|
test-tool chmtime =$just_over_2_weeks_ago .git/sharedindex.* &&
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file thirteen &&
|
2017-03-06 10:41:59 +01:00
|
|
|
git update-index --add thirteen &&
|
2017-03-06 10:42:01 +01:00
|
|
|
test $(ls .git/sharedindex.* | wc -l) -gt 2 &&
|
2017-03-06 10:41:59 +01:00
|
|
|
just_over_16_days_ago=$((-1-16*86400)) &&
|
2018-03-24 08:44:31 +01:00
|
|
|
test-tool chmtime =$just_over_16_days_ago .git/sharedindex.* &&
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file fourteen &&
|
2017-03-06 10:41:59 +01:00
|
|
|
git update-index --add fourteen &&
|
2017-03-06 10:42:01 +01:00
|
|
|
test $(ls .git/sharedindex.* | wc -l) -le 2
|
2017-03-06 10:41:59 +01:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'check splitIndex.sharedIndexExpire set to "never" and "now"' '
|
|
|
|
|
git config splitIndex.sharedIndexExpire never &&
|
|
|
|
|
just_10_years_ago=$((-365*10*86400)) &&
|
2018-03-24 08:44:31 +01:00
|
|
|
test-tool chmtime =$just_10_years_ago .git/sharedindex.* &&
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file fifteen &&
|
2017-03-06 10:41:59 +01:00
|
|
|
git update-index --add fifteen &&
|
2017-03-06 10:42:01 +01:00
|
|
|
test $(ls .git/sharedindex.* | wc -l) -gt 2 &&
|
2017-03-06 10:41:59 +01:00
|
|
|
git config splitIndex.sharedIndexExpire now &&
|
|
|
|
|
just_1_second_ago=-1 &&
|
2018-03-24 08:44:31 +01:00
|
|
|
test-tool chmtime =$just_1_second_ago .git/sharedindex.* &&
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file sixteen &&
|
2017-03-06 10:41:59 +01:00
|
|
|
git update-index --add sixteen &&
|
2017-03-06 10:42:01 +01:00
|
|
|
test $(ls .git/sharedindex.* | wc -l) -le 2
|
2017-03-06 10:41:59 +01:00
|
|
|
'
|
|
|
|
|
|
2018-11-18 20:04:29 +01:00
|
|
|
test_expect_success POSIXPERM 'same mode for index & split index' '
|
|
|
|
|
git init same-mode &&
|
|
|
|
|
(
|
|
|
|
|
cd same-mode &&
|
|
|
|
|
test_commit A &&
|
|
|
|
|
test_modebits .git/index >index_mode &&
|
|
|
|
|
test_must_fail git config core.sharedRepository &&
|
|
|
|
|
git -c core.splitIndex=true status &&
|
|
|
|
|
shared=$(ls .git/sharedindex.*) &&
|
|
|
|
|
case "$shared" in
|
|
|
|
|
*" "*)
|
|
|
|
|
# we have more than one???
|
|
|
|
|
false ;;
|
|
|
|
|
*)
|
|
|
|
|
test_modebits "$shared" >split_index_mode &&
|
|
|
|
|
test_cmp index_mode split_index_mode ;;
|
|
|
|
|
esac
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2017-06-25 06:34:29 +02:00
|
|
|
while read -r mode modebits
|
|
|
|
|
do
|
|
|
|
|
test_expect_success POSIXPERM "split index respects core.sharedrepository $mode" '
|
|
|
|
|
# Remove existing shared index files
|
|
|
|
|
git config core.splitIndex false &&
|
|
|
|
|
git update-index --force-remove one &&
|
|
|
|
|
rm -f .git/sharedindex.* &&
|
|
|
|
|
# Create one new shared index file
|
|
|
|
|
git config core.sharedrepository "$mode" &&
|
|
|
|
|
git config core.splitIndex true &&
|
t1700-split-index: date back files to avoid racy situations
't1700-split-index.sh' checks that the index was split correctly under
various circumstances and that all the different ways to turn the
split index feature on and off work correctly. To do so, most of its
tests use 'test-tool dump-split-index' to see which files have their
cache entries in the split index. All these tests assume that all
cache entries are written to the shared index (called "base"
throughout these tests) when a new shared index is created. This is
an implementation detail: most git commands (basically all except 'git
update-index') don't care or know at all about split index or whether
a cache entry is stored in the split or shared index.
As demonstrated in the previous patch, refreshing a split index is
prone to a variant of the classic racy git issue. The next patch will
fix this issue, but while doing so it will also slightly change this
behaviour: only cache entries with mtime in the past will be written
only to the newly created shared index, but racily clean cache entries
will be written to the new split index (with smudged stat data).
While this upcoming change won't at all affect any git commands, it
will violate the above mentioned assumption of 't1700's tests. Since
these tests create or modify files and create or refresh the split
index in rapid succession, there are plenty of racily clean cache
entries to be dealt with, which will then be written to the new split
indexes, and, ultimately, will cause several tests in 't1700' to fail.
Let's prepare 't1700-split-index.sh' for this upcoming change and
modify its tests to avoid racily clean files by backdating the mtime
of any file modifications (and since a lot of tests create or modify
files, encapsulate it into a helper function).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11 11:43:06 +02:00
|
|
|
create_non_racy_file one &&
|
2017-06-25 06:34:29 +02:00
|
|
|
git update-index --add one &&
|
|
|
|
|
echo "$modebits" >expect &&
|
|
|
|
|
test_modebits .git/index >actual &&
|
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
shared=$(ls .git/sharedindex.*) &&
|
|
|
|
|
case "$shared" in
|
|
|
|
|
*" "*)
|
|
|
|
|
# we have more than one???
|
|
|
|
|
false ;;
|
|
|
|
|
*)
|
|
|
|
|
test_modebits "$shared" >actual &&
|
|
|
|
|
test_cmp expect actual ;;
|
|
|
|
|
esac
|
|
|
|
|
'
|
|
|
|
|
done <<\EOF
|
|
|
|
|
0666 -rw-rw-rw-
|
|
|
|
|
0642 -rw-r---w-
|
|
|
|
|
EOF
|
|
|
|
|
|
2018-01-24 10:38:29 +01:00
|
|
|
test_expect_success POSIXPERM,SANITY 'graceful handling when splitting index is not allowed' '
|
|
|
|
|
test_create_repo ro &&
|
|
|
|
|
(
|
|
|
|
|
cd ro &&
|
|
|
|
|
test_commit initial &&
|
|
|
|
|
git update-index --split-index &&
|
|
|
|
|
test -f .git/sharedindex.*
|
|
|
|
|
) &&
|
|
|
|
|
cp ro/.git/index new-index &&
|
|
|
|
|
test_when_finished "chmod u+w ro/.git" &&
|
|
|
|
|
chmod u-w ro/.git &&
|
|
|
|
|
GIT_INDEX_FILE="$(pwd)/new-index" git -C ro update-index --split-index &&
|
|
|
|
|
chmod u+w ro/.git &&
|
|
|
|
|
rm ro/.git/sharedindex.* &&
|
|
|
|
|
GIT_INDEX_FILE=new-index git ls-files >actual &&
|
|
|
|
|
echo initial.t >expected &&
|
|
|
|
|
test_cmp expected actual
|
|
|
|
|
'
|
|
|
|
|
|
2018-01-07 23:30:14 +01:00
|
|
|
test_expect_success 'writing split index with null sha1 does not write cache tree' '
|
|
|
|
|
git config core.splitIndex true &&
|
|
|
|
|
git config splitIndex.maxPercentChange 0 &&
|
|
|
|
|
git commit -m "commit" &&
|
|
|
|
|
{
|
|
|
|
|
git ls-tree HEAD &&
|
2018-05-13 04:24:13 +02:00
|
|
|
printf "160000 commit $ZERO_OID\\tbroken\\n"
|
2018-01-07 23:30:14 +01:00
|
|
|
} >broken-tree &&
|
|
|
|
|
echo "add broken entry" >msg &&
|
|
|
|
|
|
|
|
|
|
tree=$(git mktree <broken-tree) &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
commit=$(git commit-tree $tree -p HEAD <msg) &&
|
|
|
|
|
git update-ref HEAD "$commit" &&
|
|
|
|
|
GIT_ALLOW_NULL_SHA1=1 git reset --hard &&
|
2018-07-02 02:23:41 +02:00
|
|
|
test_might_fail test-tool dump-cache-tree >cache-tree.out &&
|
2018-01-07 23:30:14 +01:00
|
|
|
test_line_count = 0 cache-tree.out
|
|
|
|
|
'
|
|
|
|
|
|
2019-02-13 10:51:29 +01:00
|
|
|
test_expect_success 'do not refresh null base index' '
|
|
|
|
|
test_create_repo merge &&
|
|
|
|
|
(
|
|
|
|
|
cd merge &&
|
|
|
|
|
test_commit initial &&
|
|
|
|
|
git checkout -b side-branch &&
|
|
|
|
|
test_commit extra &&
|
2020-11-19 00:44:21 +01:00
|
|
|
git checkout main &&
|
2019-02-13 10:51:29 +01:00
|
|
|
git update-index --split-index &&
|
|
|
|
|
test_commit more &&
|
|
|
|
|
# must not write a new shareindex, or we wont catch the problem
|
|
|
|
|
git -c splitIndex.maxPercentChange=100 merge --no-edit side-branch 2>err &&
|
|
|
|
|
# i.e. do not expect warnings like
|
|
|
|
|
# could not freshen shared index .../shareindex.00000...
|
|
|
|
|
test_must_be_empty err
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
read-cache: look for shared index files next to the index, too
When reading a split index git always looks for its referenced shared
base index in the gitdir of the current repository, even when reading
an alternate index specified via GIT_INDEX_FILE, and even when that
alternate index file is the "main" '.git/index' file of an other
repository. However, if that split index and its referenced shared
index files were written by a git command running entirely in that
other repository, then, naturally, the shared index file is written to
that other repository's gitdir. Consequently, a git command
attempting to read that shared index file while running in a different
repository won't be able find it and will error out.
I'm not sure in what use case it is necessary to read the index of one
repository by a git command running in a different repository, but it
is certainly possible to do so, and in fact the test 'bare repository:
check that --cached honors index' in 't0003-attributes.sh' does
exactly that. If GIT_TEST_SPLIT_INDEX=1 were to split the index in
just the right moment [1], then this test would indeed fail, because
the referenced shared index file could not be found.
Let's look for the referenced shared index file not only in the gitdir
of the current directory, but, if the shared index is not there, right
next to the split index as well.
[1] We haven't seen this issue trigger a failure in t0003 yet,
because:
- While GIT_TEST_SPLIT_INDEX=1 is supposed to trigger index
splitting randomly, the first index write has always been
deterministic and it has never split the index.
- That alternate index file in the other repository is written
only once in the entire test script, so it's never split.
However, the next patch will fix GIT_TEST_SPLIT_INDEX, and while
doing so it will slightly change its behavior to always split the
index already on the first index write, and t0003 would always
fail without this patch.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-26 23:00:02 +02:00
|
|
|
test_expect_success 'reading split index at alternate location' '
|
|
|
|
|
git init reading-alternate-location &&
|
|
|
|
|
(
|
|
|
|
|
cd reading-alternate-location &&
|
|
|
|
|
>file-in-alternate &&
|
|
|
|
|
git update-index --split-index --add file-in-alternate
|
|
|
|
|
) &&
|
|
|
|
|
echo file-in-alternate >expect &&
|
|
|
|
|
|
|
|
|
|
# Should be able to find the shared index both right next to
|
|
|
|
|
# the specified split index file ...
|
|
|
|
|
GIT_INDEX_FILE=./reading-alternate-location/.git/index \
|
|
|
|
|
git ls-files --cached >actual &&
|
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
|
|
# ... and, for backwards compatibility, in the current GIT_DIR
|
|
|
|
|
# as well.
|
|
|
|
|
mv -v ./reading-alternate-location/.git/sharedindex.* .git &&
|
|
|
|
|
GIT_INDEX_FILE=./reading-alternate-location/.git/index \
|
|
|
|
|
git ls-files --cached >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
read-cache: fix GIT_TEST_SPLIT_INDEX
Running tests with GIT_TEST_SPLIT_INDEX=1 is supposed to turn on the
split index feature and trigger index splitting (mostly) randomly.
Alas, this has been broken since 6e37c8ed3c (read-cache.c: fix writing
"link" index ext with null base oid, 2019-02-13), and
GIT_TEST_SPLIT_INDEX=1 hasn't triggered any index splitting since
then.
This patch makes GIT_TEST_SPLIT_INDEX work again, though it doesn't
restore the pre-6e37c8ed3c behavior. To understand the bug, the fix,
and the behavior change we first have to look at how
GIT_TEST_SPLIT_INDEX used to work before 6e37c8ed3c:
There are two places where we check the value of
GIT_TEST_SPLIT_INDEX, and before 6e37c8ed3c they worked like this:
1) In the lower-level do_write_index(), where, if
GIT_TEST_SPLIT_INDEX is enabled, we call init_split_index().
This call merely allocates and zero-initializes
'istate->split_index', but does nothing else (i.e. doesn't fill
the base/shared index with cache entries, doesn't actually
write a shared index file, etc.). Pertinent to this issue, the
hash of the base index remains all zeroed out.
2) In the higher-level write_locked_index(), but only when
'istate->split_index' has already been initialized. Then, if
GIT_TEST_SPLIT_INDEX is enabled, it randomly sets the flag that
triggers index splitting later in this function. This
randomness comes from the first byte of the hash of the base
index via an 'if ((first_byte & 15) < 6)' condition.
However, if 'istate->split_index' hasn't been initialized (i.e.
it is still NULL), then write_locked_index() just calls
do_write_locked_index(), which internally calls the above
mentioned do_write_index().
This means that while GIT_TEST_SPLIT_INDEX=1 usually triggered index
splitting randomly, the first two index writes were always
deterministic (though I suspect this was unintentional):
- The initial index write never splits the index.
During the first index write write_locked_index() is called with
'istate->split_index' still uninitialized, so the check in 2) is
not executed. It still calls do_write_index(), though, which
then executes the check in 1). The resulting all zero base
index hash then leads to the 'link' extension being written to
'.git/index', though a shared index file is not written:
$ rm .git/index
$ GIT_TEST_SPLIT_INDEX=1 git update-index --add file
$ test-tool dump-split-index .git/index
own c6ef71168597caec8553c83d9d0048f1ef416170
base 0000000000000000000000000000000000000000
100644 d00491fd7e5bb6fa28c517a0bb32b8b506539d4d 0 file
replacements:
deletions:
$ ls -l .git/sharedindex.*
ls: cannot access '.git/sharedindex.*': No such file or directory
- The second index write always splits the index.
When the index written in the previous point is read,
'istate->split_index' is initialized because of the presence of
the 'link' extension. So during the second write
write_locked_index() does run the check in 2), and the first
byte of the all zero base index hash always fulfills the
randomness condition, which in turn always triggers the index
splitting.
- Subsequent index writes will find the 'link' extension with a
real non-zero base index hash, so from then on the check in 2)
is executed and the first byte of the base index hash is as
random as it gets (coming from the SHA-1 of index data including
timestamps and inodes...).
All this worked until 6e37c8ed3c came along, and stopped writing the
'link' extension if the hash of the base index was all zero:
$ rm .git/index
$ GIT_TEST_SPLIT_INDEX=1 git update-index --add file
$ test-tool dump-split-index .git/index
own abbd6f6458d5dee73ae8e210ca15a68a390c6fd7
not a split index
$ ls -l .git/sharedindex.*
ls: cannot access '.git/sharedindex.*': No such file or directory
So, since the first index write with GIT_TEST_SPLIT_INDEX=1 doesn't
write a 'link' extension, in the second index write
'istate->split_index' remains uninitialized, and the check in 2) is
not executed, and ultimately the index is never split.
Fix this by modifying write_locked_index() to make sure to check
GIT_TEST_SPLIT_INDEX even if 'istate->split_index' is still
uninitialized, and initialize it if necessary. The check for
GIT_TEST_SPLIT_INDEX and separate init_split_index() call in
do_write_index() thus becomes unnecessary, so remove it. Furthermore,
add a test to 't1700-split-index.sh' to make sure that
GIT_TEST_SPLIT_INDEX=1 will keep working (though only check the
index splitting on the first index write, because after that it will
be random).
Note that this change does not restore the pre-6e37c8ed3c behaviour,
as it will deterministically split the index already on the first
index write. Since GIT_TEST_SPLIT_INDEX is purely a developer aid,
there is no backwards compatibility issue here. The new behaviour did
trigger test failures in 't0003-attributes.sh' and 't1600-index.sh',
though, which have been fixed in preparatory patches in this series.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-26 23:00:04 +02:00
|
|
|
test_expect_success 'GIT_TEST_SPLIT_INDEX works' '
|
|
|
|
|
git init git-test-split-index &&
|
|
|
|
|
(
|
|
|
|
|
cd git-test-split-index &&
|
|
|
|
|
>file &&
|
|
|
|
|
GIT_TEST_SPLIT_INDEX=1 git update-index --add file &&
|
|
|
|
|
ls -l .git/sharedindex.* >actual &&
|
|
|
|
|
test_line_count = 1 actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2014-06-13 14:19:51 +02:00
|
|
|
test_done
|