2014-06-13 14:19:51 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='split index mode tests'
|
|
|
|
|
|
|
|
|
|
. ./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"
|
|
|
|
|
}
|
|
|
|
|
|
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) &&
|
2015-03-20 19:20:30 +01:00
|
|
|
if test "$indexversion" = "4"
|
|
|
|
|
then
|
2018-10-10 17:59:34 +02:00
|
|
|
own=3527df833c6c100d3d1d921a9a782d62a8be4b58
|
|
|
|
|
base=746f7ab2ed44fb839efdfbffcf399d0b113fb4cb
|
2015-03-20 19:20:30 +01:00
|
|
|
else
|
2018-10-10 17:59:34 +02:00
|
|
|
own=5e9b60117ece18da410ddecc8b8d43766a0e4204
|
|
|
|
|
base=4370042739b31cd17a5c5cd6043a77c9a00df113
|
2015-03-20 19:20:30 +01:00
|
|
|
fi &&
|
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 &&
|
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 &&
|
|
|
|
|
100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 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
|
|
|
q_to_tab >expect <<-EOF &&
|
|
|
|
|
$BASE
|
|
|
|
|
100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0Q
|
|
|
|
|
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 &&
|
|
|
|
|
100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0 one
|
|
|
|
|
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
|
|
|
|
|
100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0Q
|
|
|
|
|
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 &&
|
|
|
|
|
100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 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
|
|
|
q_to_tab >expect <<-EOF &&
|
|
|
|
|
$BASE
|
|
|
|
|
100644 2e0996000b7e9019eabcad29391bf0f5c7702f0b 0Q
|
|
|
|
|
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 &&
|
|
|
|
|
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 one
|
|
|
|
|
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 three
|
|
|
|
|
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 two
|
|
|
|
|
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 &&
|
|
|
|
|
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 one
|
|
|
|
|
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 two
|
|
|
|
|
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
|
|
|
|
|
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 four
|
|
|
|
|
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
|
|
|
|
|
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 six
|
|
|
|
|
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
|
|
|
'
|
|
|
|
|
|
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
|
|
|
|
|
'
|
|
|
|
|
|
2014-06-13 14:19:51 +02:00
|
|
|
test_done
|