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
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2014-06-13 14:19:51 +02:00
|
|
|
test_done
|