2021-01-23 20:58:19 +01:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='compare full workdir to sparse workdir'
|
|
|
|
|
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
GIT_TEST_SPLIT_INDEX=0
|
2021-03-30 15:11:00 +02:00
|
|
|
GIT_TEST_SPARSE_INDEX=
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
|
2021-01-23 20:58:19 +01:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup' '
|
|
|
|
|
git init initial-repo &&
|
|
|
|
|
(
|
2021-03-30 15:10:49 +02:00
|
|
|
GIT_TEST_SPARSE_INDEX=0 &&
|
2021-01-23 20:58:19 +01:00
|
|
|
cd initial-repo &&
|
|
|
|
|
echo a >a &&
|
|
|
|
|
echo "after deep" >e &&
|
|
|
|
|
echo "after folder1" >g &&
|
|
|
|
|
echo "after x" >z &&
|
|
|
|
|
mkdir folder1 folder2 deep x &&
|
2021-07-14 15:12:28 +02:00
|
|
|
mkdir deep/deeper1 deep/deeper2 deep/before deep/later &&
|
2021-01-23 20:58:19 +01:00
|
|
|
mkdir deep/deeper1/deepest &&
|
2021-12-06 15:10:36 +01:00
|
|
|
mkdir deep/deeper1/deepest2 &&
|
|
|
|
|
mkdir deep/deeper1/deepest3 &&
|
2021-01-23 20:58:19 +01:00
|
|
|
echo "after deeper1" >deep/e &&
|
|
|
|
|
echo "after deepest" >deep/deeper1/e &&
|
|
|
|
|
cp a folder1 &&
|
|
|
|
|
cp a folder2 &&
|
|
|
|
|
cp a x &&
|
|
|
|
|
cp a deep &&
|
2021-07-14 15:12:28 +02:00
|
|
|
cp a deep/before &&
|
2021-01-23 20:58:19 +01:00
|
|
|
cp a deep/deeper1 &&
|
|
|
|
|
cp a deep/deeper2 &&
|
2021-07-14 15:12:28 +02:00
|
|
|
cp a deep/later &&
|
2021-01-23 20:58:19 +01:00
|
|
|
cp a deep/deeper1/deepest &&
|
2021-12-06 15:10:36 +01:00
|
|
|
cp a deep/deeper1/deepest2 &&
|
|
|
|
|
cp a deep/deeper1/deepest3 &&
|
|
|
|
|
cp -r deep/deeper1/ deep/deeper2 &&
|
2021-07-14 15:12:28 +02:00
|
|
|
mkdir deep/deeper1/0 &&
|
|
|
|
|
mkdir deep/deeper1/0/0 &&
|
|
|
|
|
touch deep/deeper1/0/1 &&
|
|
|
|
|
touch deep/deeper1/0/0/0 &&
|
|
|
|
|
>folder1- &&
|
|
|
|
|
>folder1.x &&
|
|
|
|
|
>folder10 &&
|
|
|
|
|
cp -r deep/deeper1/0 folder1 &&
|
|
|
|
|
cp -r deep/deeper1/0 folder2 &&
|
|
|
|
|
echo >>folder1/0/0/0 &&
|
|
|
|
|
echo >>folder2/0/1 &&
|
2021-01-23 20:58:19 +01:00
|
|
|
git add . &&
|
|
|
|
|
git commit -m "initial commit" &&
|
|
|
|
|
git checkout -b base &&
|
|
|
|
|
for dir in folder1 folder2 deep
|
|
|
|
|
do
|
2021-09-08 13:23:57 +02:00
|
|
|
git checkout -b update-$dir base &&
|
2021-01-23 20:58:19 +01:00
|
|
|
echo "updated $dir" >$dir/a &&
|
|
|
|
|
git commit -a -m "update $dir" || return 1
|
|
|
|
|
done &&
|
|
|
|
|
|
|
|
|
|
git checkout -b rename-base base &&
|
2021-07-14 15:12:27 +02:00
|
|
|
cat >folder1/larger-content <<-\EOF &&
|
2021-01-23 20:58:19 +01:00
|
|
|
matching
|
|
|
|
|
lines
|
|
|
|
|
help
|
|
|
|
|
inexact
|
|
|
|
|
renames
|
|
|
|
|
EOF
|
|
|
|
|
cp folder1/larger-content folder2/ &&
|
|
|
|
|
cp folder1/larger-content deep/deeper1/ &&
|
|
|
|
|
git add . &&
|
|
|
|
|
git commit -m "add interesting rename content" &&
|
|
|
|
|
|
|
|
|
|
git checkout -b rename-out-to-out rename-base &&
|
|
|
|
|
mv folder1/a folder2/b &&
|
|
|
|
|
mv folder1/larger-content folder2/edited-content &&
|
|
|
|
|
echo >>folder2/edited-content &&
|
2021-07-14 15:12:28 +02:00
|
|
|
echo >>folder2/0/1 &&
|
|
|
|
|
echo stuff >>deep/deeper1/a &&
|
2021-01-23 20:58:19 +01:00
|
|
|
git add . &&
|
|
|
|
|
git commit -m "rename folder1/... to folder2/..." &&
|
|
|
|
|
|
|
|
|
|
git checkout -b rename-out-to-in rename-base &&
|
|
|
|
|
mv folder1/a deep/deeper1/b &&
|
2021-07-14 15:12:28 +02:00
|
|
|
echo more stuff >>deep/deeper1/a &&
|
|
|
|
|
rm folder2/0/1 &&
|
|
|
|
|
mkdir folder2/0/1 &&
|
|
|
|
|
echo >>folder2/0/1/1 &&
|
2021-01-23 20:58:19 +01:00
|
|
|
mv folder1/larger-content deep/deeper1/edited-content &&
|
|
|
|
|
echo >>deep/deeper1/edited-content &&
|
|
|
|
|
git add . &&
|
|
|
|
|
git commit -m "rename folder1/... to deep/deeper1/..." &&
|
|
|
|
|
|
|
|
|
|
git checkout -b rename-in-to-out rename-base &&
|
|
|
|
|
mv deep/deeper1/a folder1/b &&
|
2021-07-14 15:12:28 +02:00
|
|
|
echo >>folder2/0/1 &&
|
|
|
|
|
rm -rf folder1/0/0 &&
|
|
|
|
|
echo >>folder1/0/0 &&
|
2021-01-23 20:58:19 +01:00
|
|
|
mv deep/deeper1/larger-content folder1/edited-content &&
|
|
|
|
|
echo >>folder1/edited-content &&
|
|
|
|
|
git add . &&
|
|
|
|
|
git commit -m "rename deep/deeper1/... to folder1/..." &&
|
|
|
|
|
|
t1092: document bad 'git checkout' behavior
Add new branches to the test repo that demonstrate directory/file
conflicts in different ways. Since the directory 'folder1/' has
adjacent files 'folder1-', 'folder1.txt', and 'folder10' it causes
searches for 'folder1/' to land in a different place in the index than a
search for 'folder1'. This causes a change in behavior when working with
the df-conflict-1 and df-conflict-2 branches, whose only difference is
that the first uses 'folder1' as the conflict and the other uses
'folder2' which does not have these adjacent files.
We can extend two tests that compare the behavior across different 'git
checkout' commands, and we see already that the behavior will be
different in some cases and not in others. The difference between the
two test loops is that one uses 'git reset --hard' between iterations.
Further, we isolate the behavior of creating a staged change within a
directory and then checking out a branch where that directory is
replaced with a file. A full checkout behaves differently across these
two cases, while a sparse-checkout cone behaves consistently. In both
cases, the behavior is wrong. In one case, the staged change is dropped
entirely. The other case the staged change is kept, replacing the file
at that location, but none of the other files in the directory are kept.
Likely, the correct behavior in this case is to reject the checkout and
report the conflict, leaving HEAD in its previous location. None of the
cases behave this way currently. Use comments to demonstrate that the
tested behavior is only a documentation of the current, incorrect
behavior to ensure we do not _accidentally_ change it. Instead, we would
prefer to change it on purpose with a future change.
At this point, the sparse-index does not handle these 'git checkout'
commands correctly. Or rather, it _does_ reject the 'git checkout' when
we have the staged change, but for the wrong reason. It also rejects the
'git checkout' commands when there is no staged change and we want to
replace a directory with a file. A fix for that unstaged case will
follow in the next change, but that will make the sparse-index agree
with the full checkout case in these documented incorrect behaviors.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:40 +02:00
|
|
|
git checkout -b df-conflict-1 base &&
|
|
|
|
|
rm -rf folder1 &&
|
|
|
|
|
echo content >folder1 &&
|
|
|
|
|
git add . &&
|
|
|
|
|
git commit -m "dir to file" &&
|
|
|
|
|
|
|
|
|
|
git checkout -b df-conflict-2 base &&
|
|
|
|
|
rm -rf folder2 &&
|
|
|
|
|
echo content >folder2 &&
|
|
|
|
|
git add . &&
|
|
|
|
|
git commit -m "dir to file" &&
|
|
|
|
|
|
|
|
|
|
git checkout -b fd-conflict base &&
|
|
|
|
|
rm a &&
|
|
|
|
|
mkdir a &&
|
|
|
|
|
echo content >a/a &&
|
|
|
|
|
git add . &&
|
|
|
|
|
git commit -m "file to dir" &&
|
|
|
|
|
|
2021-07-29 16:52:03 +02:00
|
|
|
for side in left right
|
|
|
|
|
do
|
|
|
|
|
git checkout -b merge-$side base &&
|
|
|
|
|
echo $side >>deep/deeper2/a &&
|
|
|
|
|
echo $side >>folder1/a &&
|
|
|
|
|
echo $side >>folder2/a &&
|
|
|
|
|
git add . &&
|
|
|
|
|
git commit -m "$side" || return 1
|
|
|
|
|
done &&
|
|
|
|
|
|
2021-01-23 20:58:19 +01:00
|
|
|
git checkout -b deepest base &&
|
|
|
|
|
echo "updated deepest" >deep/deeper1/deepest/a &&
|
2021-12-06 15:10:36 +01:00
|
|
|
echo "updated deepest2" >deep/deeper1/deepest2/a &&
|
|
|
|
|
echo "updated deepest3" >deep/deeper1/deepest3/a &&
|
2021-01-23 20:58:19 +01:00
|
|
|
git commit -a -m "update deepest" &&
|
|
|
|
|
|
|
|
|
|
git checkout -f base &&
|
|
|
|
|
git reset --hard
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
init_repos () {
|
|
|
|
|
rm -rf full-checkout sparse-checkout sparse-index &&
|
|
|
|
|
|
|
|
|
|
# create repos in initial state
|
|
|
|
|
cp -r initial-repo full-checkout &&
|
|
|
|
|
git -C full-checkout reset --hard &&
|
|
|
|
|
|
|
|
|
|
cp -r initial-repo sparse-checkout &&
|
|
|
|
|
git -C sparse-checkout reset --hard &&
|
2021-03-30 15:10:49 +02:00
|
|
|
|
|
|
|
|
cp -r initial-repo sparse-index &&
|
|
|
|
|
git -C sparse-index reset --hard &&
|
2021-01-23 20:58:19 +01:00
|
|
|
|
|
|
|
|
# initialize sparse-checkout definitions
|
2021-03-30 15:10:49 +02:00
|
|
|
git -C sparse-checkout sparse-checkout init --cone &&
|
|
|
|
|
git -C sparse-checkout sparse-checkout set deep &&
|
2021-03-30 15:11:00 +02:00
|
|
|
git -C sparse-index sparse-checkout init --cone --sparse-index &&
|
|
|
|
|
test_cmp_config -C sparse-index true index.sparse &&
|
|
|
|
|
git -C sparse-index sparse-checkout set deep
|
2021-01-23 20:58:19 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
run_on_sparse () {
|
|
|
|
|
(
|
|
|
|
|
cd sparse-checkout &&
|
2021-05-25 22:52:34 +02:00
|
|
|
GIT_PROGRESS_DELAY=100000 "$@" >../sparse-checkout-out 2>../sparse-checkout-err
|
2021-03-30 15:10:49 +02:00
|
|
|
) &&
|
|
|
|
|
(
|
|
|
|
|
cd sparse-index &&
|
2021-05-25 22:52:34 +02:00
|
|
|
GIT_PROGRESS_DELAY=100000 "$@" >../sparse-index-out 2>../sparse-index-err
|
2021-01-23 20:58:19 +01:00
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
run_on_all () {
|
|
|
|
|
(
|
|
|
|
|
cd full-checkout &&
|
2021-05-25 22:52:34 +02:00
|
|
|
GIT_PROGRESS_DELAY=100000 "$@" >../full-checkout-out 2>../full-checkout-err
|
2021-01-23 20:58:19 +01:00
|
|
|
) &&
|
2021-03-30 15:10:46 +02:00
|
|
|
run_on_sparse "$@"
|
2021-01-23 20:58:19 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test_all_match () {
|
2021-03-30 15:10:46 +02:00
|
|
|
run_on_all "$@" &&
|
2021-01-23 20:58:19 +01:00
|
|
|
test_cmp full-checkout-out sparse-checkout-out &&
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
test_cmp full-checkout-out sparse-index-out &&
|
|
|
|
|
test_cmp full-checkout-err sparse-checkout-err &&
|
|
|
|
|
test_cmp full-checkout-err sparse-index-err
|
2021-01-23 20:58:19 +01:00
|
|
|
}
|
|
|
|
|
|
2021-03-30 15:10:49 +02:00
|
|
|
test_sparse_match () {
|
|
|
|
|
run_on_sparse "$@" &&
|
|
|
|
|
test_cmp sparse-checkout-out sparse-index-out &&
|
|
|
|
|
test_cmp sparse-checkout-err sparse-index-err
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-24 17:39:03 +02:00
|
|
|
test_sparse_unstaged () {
|
|
|
|
|
file=$1 &&
|
|
|
|
|
for repo in sparse-checkout sparse-index
|
|
|
|
|
do
|
|
|
|
|
# Skip "unmerged" paths
|
|
|
|
|
git -C $repo diff --staged --diff-filter=u -- "$file" >diff &&
|
|
|
|
|
test_must_be_empty diff || return 1
|
|
|
|
|
done
|
|
|
|
|
}
|
|
|
|
|
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
test_expect_success 'sparse-index contents' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
test-tool -C sparse-index read-cache --table >cache &&
|
|
|
|
|
for dir in folder1 folder2 x
|
|
|
|
|
do
|
|
|
|
|
TREE=$(git -C sparse-index rev-parse HEAD:$dir) &&
|
|
|
|
|
grep "040000 tree $TREE $dir/" cache \
|
|
|
|
|
|| return 1
|
|
|
|
|
done &&
|
|
|
|
|
|
2021-03-30 15:11:00 +02:00
|
|
|
git -C sparse-index sparse-checkout set folder1 &&
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
|
|
|
|
|
test-tool -C sparse-index read-cache --table >cache &&
|
|
|
|
|
for dir in deep folder2 x
|
|
|
|
|
do
|
|
|
|
|
TREE=$(git -C sparse-index rev-parse HEAD:$dir) &&
|
|
|
|
|
grep "040000 tree $TREE $dir/" cache \
|
|
|
|
|
|| return 1
|
|
|
|
|
done &&
|
|
|
|
|
|
2021-03-30 15:11:00 +02:00
|
|
|
git -C sparse-index sparse-checkout set deep/deeper1 &&
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
|
|
|
|
|
test-tool -C sparse-index read-cache --table >cache &&
|
|
|
|
|
for dir in deep/deeper2 folder1 folder2 x
|
|
|
|
|
do
|
|
|
|
|
TREE=$(git -C sparse-index rev-parse HEAD:$dir) &&
|
|
|
|
|
grep "040000 tree $TREE $dir/" cache \
|
|
|
|
|
|| return 1
|
2021-03-30 15:11:00 +02:00
|
|
|
done &&
|
|
|
|
|
|
|
|
|
|
# Disabling the sparse-index removes tree entries with full ones
|
|
|
|
|
git -C sparse-index sparse-checkout init --no-sparse-index &&
|
|
|
|
|
|
|
|
|
|
test-tool -C sparse-index read-cache --table >cache &&
|
|
|
|
|
! grep "040000 tree" cache &&
|
|
|
|
|
test_sparse_match test-tool read-cache --table
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
'
|
|
|
|
|
|
2021-03-30 15:10:51 +02:00
|
|
|
test_expect_success 'expanded in-memory index matches full index' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
test_sparse_match test-tool read-cache --expand --table
|
|
|
|
|
'
|
|
|
|
|
|
2021-01-23 20:58:19 +01:00
|
|
|
test_expect_success 'status with options' '
|
|
|
|
|
init_repos &&
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
test_sparse_match ls &&
|
2021-01-23 20:58:19 +01:00
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git status --porcelain=v2 -z -u &&
|
|
|
|
|
test_all_match git status --porcelain=v2 -uno &&
|
2021-03-30 15:10:46 +02:00
|
|
|
run_on_all touch README.md &&
|
2021-01-23 20:58:19 +01:00
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git status --porcelain=v2 -z -u &&
|
|
|
|
|
test_all_match git status --porcelain=v2 -uno &&
|
|
|
|
|
test_all_match git add README.md &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git status --porcelain=v2 -z -u &&
|
|
|
|
|
test_all_match git status --porcelain=v2 -uno
|
|
|
|
|
'
|
|
|
|
|
|
2021-07-14 15:12:36 +02:00
|
|
|
test_expect_success 'status reports sparse-checkout' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
git -C sparse-checkout status >full &&
|
|
|
|
|
git -C sparse-index status >sparse &&
|
|
|
|
|
test_i18ngrep "You are in a sparse checkout with " full &&
|
|
|
|
|
test_i18ngrep "You are in a sparse checkout." sparse
|
|
|
|
|
'
|
|
|
|
|
|
2021-01-23 20:58:19 +01:00
|
|
|
test_expect_success 'add, commit, checkout' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
write_script edit-contents <<-\EOF &&
|
|
|
|
|
echo text >>$1
|
|
|
|
|
EOF
|
2021-03-30 15:10:46 +02:00
|
|
|
run_on_all ../edit-contents README.md &&
|
2021-01-23 20:58:19 +01:00
|
|
|
|
|
|
|
|
test_all_match git add README.md &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git commit -m "Add README.md" &&
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout HEAD~1 &&
|
|
|
|
|
test_all_match git checkout - &&
|
|
|
|
|
|
2021-03-30 15:10:46 +02:00
|
|
|
run_on_all ../edit-contents README.md &&
|
2021-01-23 20:58:19 +01:00
|
|
|
|
|
|
|
|
test_all_match git add -A &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git commit -m "Extend README.md" &&
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout HEAD~1 &&
|
|
|
|
|
test_all_match git checkout - &&
|
|
|
|
|
|
2021-03-30 15:10:46 +02:00
|
|
|
run_on_all ../edit-contents deep/newfile &&
|
2021-01-23 20:58:19 +01:00
|
|
|
|
|
|
|
|
test_all_match git status --porcelain=v2 -uno &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git add . &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git commit -m "add deep/newfile" &&
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout HEAD~1 &&
|
|
|
|
|
test_all_match git checkout -
|
|
|
|
|
'
|
|
|
|
|
|
unpack-trees: use traverse_path instead of name
The sparse_dir_matches_path() method compares a cache entry that is a
sparse directory entry against a 'struct traverse_info *info' and a
'struct name_entry *p' to see if the cache entry has exactly the right
name for those other inputs.
This method was introduced in 523506d (unpack-trees: unpack sparse
directory entries, 2021-07-14), but included a significant mistake. The
path comparisons used 'info->name' instead of 'info->traverse_path'.
Since 'info->name' only stores a single tree entry name while
'info->traverse_path' stores the full path from root, this method does
not work when 'info' is in a subdirectory of a directory. Replacing the
right strings and their corresponding lengths make the method work
properly.
The previous change included a failing test that exposes this issue.
That test now passes. The critical detail is that as we go deep into
unpack_trees(), the logic for merging a sparse directory entry with a
tree entry during 'git checkout' relies on this
sparse_dir_matches_path() in order to avoid calling
traverse_trees_recursive() during unpack_callback() in this hunk:
if (!is_sparse_directory_entry(src[0], names, info) &&
traverse_trees_recursive(n, dirmask, mask & ~dirmask,
names, info) < 0) {
return -1;
}
For deep paths, the short-circuit never occurred and
traverse_trees_recursive() was being called incorrectly and that was
causing other strange issues. Specifically, the error message from the
now-passing test previously included this:
error: Your local changes to the following files would be overwritten by checkout:
deep/deeper1/deepest2/a
deep/deeper1/deepest3/a
Please commit your changes or stash them before you switch branches.
Aborting
These messages occurred because the 'current' cache entry in
twoway_merge() was showing as NULL because the index did not contain
entries for the paths contained within the sparse directory entries. We
instead had 'oldtree' given as the entry at HEAD and 'newtree' as the
entry in the target tree. This led to reject_merge() listing these
paths.
Now that sparse_dir_matches_path() works the same for deep paths as it
does for shallow depths, the rest of the logic kicks in to properly
handle modifying the sparse directory entries as designed.
Reported-by: Gustave Granroth <gus.gran@gmail.com>
Reported-by: Mike Marcelais <michmarc@exchange.microsoft.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-06 15:10:37 +01:00
|
|
|
test_expect_success 'deep changes during checkout' '
|
2021-12-06 15:10:36 +01:00
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
test_sparse_match git sparse-checkout set deep/deeper1/deepest &&
|
|
|
|
|
test_all_match git checkout deepest &&
|
|
|
|
|
test_all_match git checkout base
|
|
|
|
|
'
|
|
|
|
|
|
2021-09-24 17:39:03 +02:00
|
|
|
test_expect_success 'add outside sparse cone' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
run_on_sparse mkdir folder1 &&
|
|
|
|
|
run_on_sparse ../edit-contents folder1/a &&
|
|
|
|
|
run_on_sparse ../edit-contents folder1/newfile &&
|
|
|
|
|
test_sparse_match test_must_fail git add folder1/a &&
|
|
|
|
|
grep "Disable or modify the sparsity rules" sparse-checkout-err &&
|
|
|
|
|
test_sparse_unstaged folder1/a &&
|
2021-09-24 17:39:06 +02:00
|
|
|
test_sparse_match test_must_fail git add folder1/newfile &&
|
|
|
|
|
grep "Disable or modify the sparsity rules" sparse-checkout-err &&
|
|
|
|
|
test_sparse_unstaged folder1/newfile
|
2021-09-24 17:39:03 +02:00
|
|
|
'
|
|
|
|
|
|
2021-06-29 04:13:04 +02:00
|
|
|
test_expect_success 'commit including unstaged changes' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
write_script edit-file <<-\EOF &&
|
|
|
|
|
echo $1 >$2
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
run_on_all ../edit-file 1 a &&
|
|
|
|
|
run_on_all ../edit-file 1 deep/a &&
|
|
|
|
|
|
|
|
|
|
test_all_match git commit -m "-a" -a &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
run_on_all ../edit-file 2 a &&
|
|
|
|
|
run_on_all ../edit-file 2 deep/a &&
|
|
|
|
|
|
|
|
|
|
test_all_match git commit -m "--include" --include deep/a &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git commit -m "--include" --include a &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
run_on_all ../edit-file 3 a &&
|
|
|
|
|
run_on_all ../edit-file 3 deep/a &&
|
|
|
|
|
|
|
|
|
|
test_all_match git commit -m "--amend" -a --amend &&
|
|
|
|
|
test_all_match git status --porcelain=v2
|
|
|
|
|
'
|
|
|
|
|
|
2021-09-24 17:39:08 +02:00
|
|
|
test_expect_success 'status/add: outside sparse cone' '
|
2021-07-14 15:12:29 +02:00
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
# folder1 is at HEAD, but outside the sparse cone
|
|
|
|
|
run_on_sparse mkdir folder1 &&
|
|
|
|
|
cp initial-repo/folder1/a sparse-checkout/folder1/a &&
|
|
|
|
|
cp initial-repo/folder1/a sparse-index/folder1/a &&
|
|
|
|
|
|
|
|
|
|
test_sparse_match git status &&
|
|
|
|
|
|
|
|
|
|
write_script edit-contents <<-\EOF &&
|
|
|
|
|
echo text >>$1
|
|
|
|
|
EOF
|
|
|
|
|
run_on_sparse ../edit-contents folder1/a &&
|
|
|
|
|
run_on_all ../edit-contents folder1/new &&
|
|
|
|
|
|
|
|
|
|
test_sparse_match git status --porcelain=v2 &&
|
|
|
|
|
|
2021-07-29 16:52:04 +02:00
|
|
|
# Adding the path outside of the sparse-checkout cone should fail.
|
2021-07-14 15:12:29 +02:00
|
|
|
test_sparse_match test_must_fail git add folder1/a &&
|
2021-09-24 17:39:03 +02:00
|
|
|
grep "Disable or modify the sparsity rules" sparse-checkout-err &&
|
|
|
|
|
test_sparse_unstaged folder1/a &&
|
2021-07-29 16:52:06 +02:00
|
|
|
test_sparse_match test_must_fail git add --refresh folder1/a &&
|
2021-09-24 17:39:03 +02:00
|
|
|
grep "Disable or modify the sparsity rules" sparse-checkout-err &&
|
|
|
|
|
test_sparse_unstaged folder1/a &&
|
2021-09-24 17:39:06 +02:00
|
|
|
test_sparse_match test_must_fail git add folder1/new &&
|
|
|
|
|
grep "Disable or modify the sparsity rules" sparse-checkout-err &&
|
|
|
|
|
test_sparse_unstaged folder1/new &&
|
2021-09-24 17:39:08 +02:00
|
|
|
test_sparse_match git add --sparse folder1/a &&
|
|
|
|
|
test_sparse_match git add --sparse folder1/new &&
|
2021-07-29 16:52:04 +02:00
|
|
|
|
2021-09-24 17:39:08 +02:00
|
|
|
test_all_match git add --sparse . &&
|
2021-07-14 15:12:29 +02:00
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git commit -m folder1/new &&
|
2021-07-29 16:52:04 +02:00
|
|
|
test_all_match git rev-parse HEAD^{tree} &&
|
2021-07-14 15:12:29 +02:00
|
|
|
|
|
|
|
|
run_on_all ../edit-contents folder1/newer &&
|
2021-09-24 17:39:08 +02:00
|
|
|
test_all_match git add --sparse folder1/ &&
|
2021-07-14 15:12:29 +02:00
|
|
|
test_all_match git status --porcelain=v2 &&
|
2021-07-29 16:52:04 +02:00
|
|
|
test_all_match git commit -m folder1/newer &&
|
|
|
|
|
test_all_match git rev-parse HEAD^{tree}
|
2021-07-14 15:12:29 +02:00
|
|
|
'
|
|
|
|
|
|
2021-01-23 20:58:19 +01:00
|
|
|
test_expect_success 'checkout and reset --hard' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout update-folder1 &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout update-deep &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout -b reset-test &&
|
|
|
|
|
test_all_match git reset --hard deepest &&
|
|
|
|
|
test_all_match git reset --hard update-folder1 &&
|
|
|
|
|
test_all_match git reset --hard update-folder2
|
|
|
|
|
'
|
|
|
|
|
|
2021-12-06 16:55:59 +01:00
|
|
|
test_expect_success 'diff --cached' '
|
2021-01-23 20:58:19 +01:00
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
write_script edit-contents <<-\EOF &&
|
|
|
|
|
echo text >>README.md
|
|
|
|
|
EOF
|
2021-03-30 15:10:46 +02:00
|
|
|
run_on_all ../edit-contents &&
|
2021-01-23 20:58:19 +01:00
|
|
|
|
|
|
|
|
test_all_match git diff &&
|
2021-12-06 16:55:59 +01:00
|
|
|
test_all_match git diff --cached &&
|
2021-01-23 20:58:19 +01:00
|
|
|
test_all_match git add README.md &&
|
|
|
|
|
test_all_match git diff &&
|
2021-12-06 16:55:59 +01:00
|
|
|
test_all_match git diff --cached
|
2021-01-23 20:58:19 +01:00
|
|
|
'
|
|
|
|
|
|
t1092: document bad 'git checkout' behavior
Add new branches to the test repo that demonstrate directory/file
conflicts in different ways. Since the directory 'folder1/' has
adjacent files 'folder1-', 'folder1.txt', and 'folder10' it causes
searches for 'folder1/' to land in a different place in the index than a
search for 'folder1'. This causes a change in behavior when working with
the df-conflict-1 and df-conflict-2 branches, whose only difference is
that the first uses 'folder1' as the conflict and the other uses
'folder2' which does not have these adjacent files.
We can extend two tests that compare the behavior across different 'git
checkout' commands, and we see already that the behavior will be
different in some cases and not in others. The difference between the
two test loops is that one uses 'git reset --hard' between iterations.
Further, we isolate the behavior of creating a staged change within a
directory and then checking out a branch where that directory is
replaced with a file. A full checkout behaves differently across these
two cases, while a sparse-checkout cone behaves consistently. In both
cases, the behavior is wrong. In one case, the staged change is dropped
entirely. The other case the staged change is kept, replacing the file
at that location, but none of the other files in the directory are kept.
Likely, the correct behavior in this case is to reject the checkout and
report the conflict, leaving HEAD in its previous location. None of the
cases behave this way currently. Use comments to demonstrate that the
tested behavior is only a documentation of the current, incorrect
behavior to ensure we do not _accidentally_ change it. Instead, we would
prefer to change it on purpose with a future change.
At this point, the sparse-index does not handle these 'git checkout'
commands correctly. Or rather, it _does_ reject the 'git checkout' when
we have the staged change, but for the wrong reason. It also rejects the
'git checkout' commands when there is no staged change and we want to
replace a directory with a file. A fix for that unstaged case will
follow in the next change, but that will make the sparse-index agree
with the full checkout case in these documented incorrect behaviors.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:40 +02:00
|
|
|
# NEEDSWORK: sparse-checkout behaves differently from full-checkout when
|
|
|
|
|
# running this test with 'df-conflict-2' after 'df-conflict-1'.
|
2021-07-14 15:12:28 +02:00
|
|
|
test_expect_success 'diff with renames and conflicts' '
|
2021-01-23 20:58:19 +01:00
|
|
|
init_repos &&
|
|
|
|
|
|
t1092: document bad 'git checkout' behavior
Add new branches to the test repo that demonstrate directory/file
conflicts in different ways. Since the directory 'folder1/' has
adjacent files 'folder1-', 'folder1.txt', and 'folder10' it causes
searches for 'folder1/' to land in a different place in the index than a
search for 'folder1'. This causes a change in behavior when working with
the df-conflict-1 and df-conflict-2 branches, whose only difference is
that the first uses 'folder1' as the conflict and the other uses
'folder2' which does not have these adjacent files.
We can extend two tests that compare the behavior across different 'git
checkout' commands, and we see already that the behavior will be
different in some cases and not in others. The difference between the
two test loops is that one uses 'git reset --hard' between iterations.
Further, we isolate the behavior of creating a staged change within a
directory and then checking out a branch where that directory is
replaced with a file. A full checkout behaves differently across these
two cases, while a sparse-checkout cone behaves consistently. In both
cases, the behavior is wrong. In one case, the staged change is dropped
entirely. The other case the staged change is kept, replacing the file
at that location, but none of the other files in the directory are kept.
Likely, the correct behavior in this case is to reject the checkout and
report the conflict, leaving HEAD in its previous location. None of the
cases behave this way currently. Use comments to demonstrate that the
tested behavior is only a documentation of the current, incorrect
behavior to ensure we do not _accidentally_ change it. Instead, we would
prefer to change it on purpose with a future change.
At this point, the sparse-index does not handle these 'git checkout'
commands correctly. Or rather, it _does_ reject the 'git checkout' when
we have the staged change, but for the wrong reason. It also rejects the
'git checkout' commands when there is no staged change and we want to
replace a directory with a file. A fix for that unstaged case will
follow in the next change, but that will make the sparse-index agree
with the full checkout case in these documented incorrect behaviors.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:40 +02:00
|
|
|
for branch in rename-out-to-out \
|
|
|
|
|
rename-out-to-in \
|
|
|
|
|
rename-in-to-out \
|
|
|
|
|
df-conflict-1 \
|
|
|
|
|
fd-conflict
|
2021-01-23 20:58:19 +01:00
|
|
|
do
|
|
|
|
|
test_all_match git checkout rename-base &&
|
2021-07-14 15:12:28 +02:00
|
|
|
test_all_match git checkout $branch -- . &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
2021-12-06 16:55:59 +01:00
|
|
|
test_all_match git diff --cached --no-renames &&
|
|
|
|
|
test_all_match git diff --cached --find-renames || return 1
|
2021-07-14 15:12:28 +02:00
|
|
|
done
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'diff with directory/file conflicts' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
t1092: document bad 'git checkout' behavior
Add new branches to the test repo that demonstrate directory/file
conflicts in different ways. Since the directory 'folder1/' has
adjacent files 'folder1-', 'folder1.txt', and 'folder10' it causes
searches for 'folder1/' to land in a different place in the index than a
search for 'folder1'. This causes a change in behavior when working with
the df-conflict-1 and df-conflict-2 branches, whose only difference is
that the first uses 'folder1' as the conflict and the other uses
'folder2' which does not have these adjacent files.
We can extend two tests that compare the behavior across different 'git
checkout' commands, and we see already that the behavior will be
different in some cases and not in others. The difference between the
two test loops is that one uses 'git reset --hard' between iterations.
Further, we isolate the behavior of creating a staged change within a
directory and then checking out a branch where that directory is
replaced with a file. A full checkout behaves differently across these
two cases, while a sparse-checkout cone behaves consistently. In both
cases, the behavior is wrong. In one case, the staged change is dropped
entirely. The other case the staged change is kept, replacing the file
at that location, but none of the other files in the directory are kept.
Likely, the correct behavior in this case is to reject the checkout and
report the conflict, leaving HEAD in its previous location. None of the
cases behave this way currently. Use comments to demonstrate that the
tested behavior is only a documentation of the current, incorrect
behavior to ensure we do not _accidentally_ change it. Instead, we would
prefer to change it on purpose with a future change.
At this point, the sparse-index does not handle these 'git checkout'
commands correctly. Or rather, it _does_ reject the 'git checkout' when
we have the staged change, but for the wrong reason. It also rejects the
'git checkout' commands when there is no staged change and we want to
replace a directory with a file. A fix for that unstaged case will
follow in the next change, but that will make the sparse-index agree
with the full checkout case in these documented incorrect behaviors.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:40 +02:00
|
|
|
for branch in rename-out-to-out \
|
|
|
|
|
rename-out-to-in \
|
|
|
|
|
rename-in-to-out \
|
unpack-trees: resolve sparse-directory/file conflicts
When running unpack_trees() with a sparse index, we attempt to operate
on the index without expanding the sparse directory entries. Thus, we
operate by manipulating entire directories and passing them to the
unpack function. In the case of the 'git checkout' command, this is the
twoway_merge() function.
There are several cases in twoway_merge() that handle different
situations. One new one to add is the case of a directory/file conflict
where the directory is sparse. Before the sparse index, such a conflict
would appear as a list of file additions and deletions. Now,
twoway_merge() initializes 'current', 'oldtree', and 'newtree' from
src[0], src[1], and src[2], then sets 'oldtree' to NULL because it is
equal to the df_conflict_entry. The way to determine that we have a
directory/file conflict is to test that 'current' and 'newtree' disagree
on being sparse directory entries.
When we are in this case, we want to resolve the situation by calling
merged_entry(). This allows replacing the 'current' entry with the
'newtree' entry. This is important for cases where we want to run 'git
checkout' across the conflict and have the new HEAD represent the new
file type at that path. The first NEEDSWORK comment dropped in t1092
demonstrates this necessary behavior.
However, we still are in a confusing state when 'current' corresponds to
a staged change within a sparse directory that is not present at HEAD.
This should be atypical, because it requires adding a change outside of
the sparse-checkout cone, but it is possible. Since we are unable to
determine that this is a staged change within twoway_merge(), we cannot
add a case to reject the merge at this point. I believe this is due to
the use of df_conflict_entry in the place of 'oldtree' instead of using
the valud at HEAD, which would provide some perspective to this
decision. Any change that would allow this differentiation for staged
entries would need to involve information further up in unpack_trees().
That work should be done, sometime, because we are further confusing the
behavior of a directory/file conflict when staging a change in the
directory. The two cases 'checkout behaves oddly with df-conflict-?' in
t1092 demonstrate that even without a sparse-checkout, Git is not
consistent in its behavior. Neither of the two options seems correct,
either. This change makes the sparse-index behave differently than the
typcial sparse-checkout case, but it does match the full checkout
behavior in the df-conflict-2 case.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:41 +02:00
|
|
|
df-conflict-1 \
|
|
|
|
|
df-conflict-2 \
|
t1092: document bad 'git checkout' behavior
Add new branches to the test repo that demonstrate directory/file
conflicts in different ways. Since the directory 'folder1/' has
adjacent files 'folder1-', 'folder1.txt', and 'folder10' it causes
searches for 'folder1/' to land in a different place in the index than a
search for 'folder1'. This causes a change in behavior when working with
the df-conflict-1 and df-conflict-2 branches, whose only difference is
that the first uses 'folder1' as the conflict and the other uses
'folder2' which does not have these adjacent files.
We can extend two tests that compare the behavior across different 'git
checkout' commands, and we see already that the behavior will be
different in some cases and not in others. The difference between the
two test loops is that one uses 'git reset --hard' between iterations.
Further, we isolate the behavior of creating a staged change within a
directory and then checking out a branch where that directory is
replaced with a file. A full checkout behaves differently across these
two cases, while a sparse-checkout cone behaves consistently. In both
cases, the behavior is wrong. In one case, the staged change is dropped
entirely. The other case the staged change is kept, replacing the file
at that location, but none of the other files in the directory are kept.
Likely, the correct behavior in this case is to reject the checkout and
report the conflict, leaving HEAD in its previous location. None of the
cases behave this way currently. Use comments to demonstrate that the
tested behavior is only a documentation of the current, incorrect
behavior to ensure we do not _accidentally_ change it. Instead, we would
prefer to change it on purpose with a future change.
At this point, the sparse-index does not handle these 'git checkout'
commands correctly. Or rather, it _does_ reject the 'git checkout' when
we have the staged change, but for the wrong reason. It also rejects the
'git checkout' commands when there is no staged change and we want to
replace a directory with a file. A fix for that unstaged case will
follow in the next change, but that will make the sparse-index agree
with the full checkout case in these documented incorrect behaviors.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:40 +02:00
|
|
|
fd-conflict
|
2021-07-14 15:12:28 +02:00
|
|
|
do
|
|
|
|
|
git -C full-checkout reset --hard &&
|
|
|
|
|
test_sparse_match git reset --hard &&
|
|
|
|
|
test_all_match git checkout $branch &&
|
|
|
|
|
test_all_match git checkout rename-base -- . &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
2021-12-06 16:55:59 +01:00
|
|
|
test_all_match git diff --cached --no-renames &&
|
|
|
|
|
test_all_match git diff --cached --find-renames || return 1
|
2021-01-23 20:58:19 +01:00
|
|
|
done
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'log with pathspec outside sparse definition' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
test_all_match git log -- a &&
|
|
|
|
|
test_all_match git log -- folder1/a &&
|
|
|
|
|
test_all_match git log -- folder2/a &&
|
|
|
|
|
test_all_match git log -- deep/a &&
|
|
|
|
|
test_all_match git log -- deep/deeper1/a &&
|
|
|
|
|
test_all_match git log -- deep/deeper1/deepest/a &&
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout update-folder1 &&
|
|
|
|
|
test_all_match git log -- folder1/a
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'blame with pathspec inside sparse definition' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
2021-12-06 16:56:01 +01:00
|
|
|
for file in a \
|
|
|
|
|
deep/a \
|
|
|
|
|
deep/deeper1/a \
|
|
|
|
|
deep/deeper1/deepest/a
|
|
|
|
|
do
|
|
|
|
|
test_all_match git blame $file
|
|
|
|
|
done
|
2021-01-23 20:58:19 +01:00
|
|
|
'
|
|
|
|
|
|
2021-12-06 16:56:01 +01:00
|
|
|
# Without a revision specified, blame will error if passed any file that
|
|
|
|
|
# is not present in the working directory (even if the file is tracked).
|
|
|
|
|
# Here we just verify that this is also true with sparse checkouts.
|
|
|
|
|
test_expect_success 'blame with pathspec outside sparse definition' '
|
2021-01-23 20:58:19 +01:00
|
|
|
init_repos &&
|
2021-12-06 16:56:01 +01:00
|
|
|
test_sparse_match git sparse-checkout set &&
|
2021-01-23 20:58:19 +01:00
|
|
|
|
2021-12-06 16:56:01 +01:00
|
|
|
for file in a \
|
|
|
|
|
deep/a \
|
|
|
|
|
deep/deeper1/a \
|
|
|
|
|
deep/deeper1/deepest/a
|
|
|
|
|
do
|
|
|
|
|
test_sparse_match test_must_fail git blame $file &&
|
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
fatal: Cannot lstat '"'"'$file'"'"': No such file or directory
|
|
|
|
|
EOF
|
|
|
|
|
# We compare sparse-checkout-err and sparse-index-err in
|
|
|
|
|
# `test_sparse_match`. Given we know they are the same, we
|
|
|
|
|
# only check the content of sparse-index-err here.
|
|
|
|
|
test_cmp expect sparse-index-err
|
|
|
|
|
done
|
2021-01-23 20:58:19 +01:00
|
|
|
'
|
|
|
|
|
|
reset: preserve skip-worktree bit in mixed reset
Change `update_index_from_diff` to set `skip-worktree` when applicable for
new index entries. When `git reset --mixed <tree-ish>` is run, entries in
the index with differences between the pre-reset HEAD and reset <tree-ish>
are identified and handled with `update_index_from_diff`. For each file, a
new cache entry in inserted into the index, created from the <tree-ish> side
of the reset (without changing the working tree). However, the newly-created
entry must have `skip-worktree` explicitly set in either of the following
scenarios:
1. the file is in the current index and has `skip-worktree` set
2. the file is not in the current index but is outside of a defined sparse
checkout definition
Not setting the `skip-worktree` bit leads to likely-undesirable results for
a user. It causes `skip-worktree` settings to disappear on the
"diff"-containing files (but *only* the diff-containing files), leading to
those files now showing modifications in `git status`. For example, when
running `git reset --mixed` in a sparse checkout, some file entries outside
of sparse checkout could show up as deleted, despite the user never deleting
anything (and not wanting them on-disk anyway).
Additionally, add a test to `t7102` to ensure `skip-worktree` is preserved
in a basic `git reset --mixed` scenario and update a failure-documenting
test from 19a0acc (t1092: test interesting sparse-checkout scenarios,
2021-01-23) with new expected behavior.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-27 16:39:17 +02:00
|
|
|
test_expect_success 'checkout and reset (mixed)' '
|
2021-01-23 20:58:19 +01:00
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout -b reset-test update-deep &&
|
|
|
|
|
test_all_match git reset deepest &&
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
|
reset: preserve skip-worktree bit in mixed reset
Change `update_index_from_diff` to set `skip-worktree` when applicable for
new index entries. When `git reset --mixed <tree-ish>` is run, entries in
the index with differences between the pre-reset HEAD and reset <tree-ish>
are identified and handled with `update_index_from_diff`. For each file, a
new cache entry in inserted into the index, created from the <tree-ish> side
of the reset (without changing the working tree). However, the newly-created
entry must have `skip-worktree` explicitly set in either of the following
scenarios:
1. the file is in the current index and has `skip-worktree` set
2. the file is not in the current index but is outside of a defined sparse
checkout definition
Not setting the `skip-worktree` bit leads to likely-undesirable results for
a user. It causes `skip-worktree` settings to disappear on the
"diff"-containing files (but *only* the diff-containing files), leading to
those files now showing modifications in `git status`. For example, when
running `git reset --mixed` in a sparse checkout, some file entries outside
of sparse checkout could show up as deleted, despite the user never deleting
anything (and not wanting them on-disk anyway).
Additionally, add a test to `t7102` to ensure `skip-worktree` is preserved
in a basic `git reset --mixed` scenario and update a failure-documenting
test from 19a0acc (t1092: test interesting sparse-checkout scenarios,
2021-01-23) with new expected behavior.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-27 16:39:17 +02:00
|
|
|
# Because skip-worktree is preserved, resetting to update-folder1
|
|
|
|
|
# will show worktree changes for folder1/a in full-checkout, but not
|
|
|
|
|
# in sparse-checkout or sparse-index.
|
|
|
|
|
git -C full-checkout reset update-folder1 >full-checkout-out &&
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
test_sparse_match git reset update-folder1 &&
|
reset: preserve skip-worktree bit in mixed reset
Change `update_index_from_diff` to set `skip-worktree` when applicable for
new index entries. When `git reset --mixed <tree-ish>` is run, entries in
the index with differences between the pre-reset HEAD and reset <tree-ish>
are identified and handled with `update_index_from_diff`. For each file, a
new cache entry in inserted into the index, created from the <tree-ish> side
of the reset (without changing the working tree). However, the newly-created
entry must have `skip-worktree` explicitly set in either of the following
scenarios:
1. the file is in the current index and has `skip-worktree` set
2. the file is not in the current index but is outside of a defined sparse
checkout definition
Not setting the `skip-worktree` bit leads to likely-undesirable results for
a user. It causes `skip-worktree` settings to disappear on the
"diff"-containing files (but *only* the diff-containing files), leading to
those files now showing modifications in `git status`. For example, when
running `git reset --mixed` in a sparse checkout, some file entries outside
of sparse checkout could show up as deleted, despite the user never deleting
anything (and not wanting them on-disk anyway).
Additionally, add a test to `t7102` to ensure `skip-worktree` is preserved
in a basic `git reset --mixed` scenario and update a failure-documenting
test from 19a0acc (t1092: test interesting sparse-checkout scenarios,
2021-01-23) with new expected behavior.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-27 16:39:17 +02:00
|
|
|
grep "M folder1/a" full-checkout-out &&
|
|
|
|
|
! grep "M folder1/a" sparse-checkout-out &&
|
|
|
|
|
run_on_sparse test_path_is_missing folder1
|
2021-01-23 20:58:19 +01:00
|
|
|
'
|
|
|
|
|
|
2021-11-29 16:52:39 +01:00
|
|
|
test_expect_success 'checkout and reset (merge)' '
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
init_repos &&
|
|
|
|
|
|
2021-11-29 16:52:39 +01:00
|
|
|
write_script edit-contents <<-\EOF &&
|
|
|
|
|
echo text >>$1
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout -b reset-test update-deep &&
|
|
|
|
|
run_on_all ../edit-contents a &&
|
|
|
|
|
test_all_match git reset --merge deepest &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
test_all_match git reset --hard update-deep &&
|
|
|
|
|
run_on_all ../edit-contents deep/a &&
|
|
|
|
|
test_all_match test_must_fail git reset --merge deepest
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'checkout and reset (keep)' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
write_script edit-contents <<-\EOF &&
|
|
|
|
|
echo text >>$1
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout -b reset-test update-deep &&
|
|
|
|
|
run_on_all ../edit-contents a &&
|
|
|
|
|
test_all_match git reset --keep deepest &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
test_all_match git reset --hard update-deep &&
|
|
|
|
|
run_on_all ../edit-contents deep/a &&
|
|
|
|
|
test_all_match test_must_fail git reset --keep deepest
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'reset with pathspecs inside sparse definition' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
write_script edit-contents <<-\EOF &&
|
|
|
|
|
echo text >>$1
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout -b reset-test update-deep &&
|
|
|
|
|
run_on_all ../edit-contents deep/a &&
|
|
|
|
|
|
|
|
|
|
test_all_match git reset base -- deep/a &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
test_all_match git reset base -- nonexistent-file &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
test_all_match git reset deepest -- deep &&
|
|
|
|
|
test_all_match git status --porcelain=v2
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
# Although the working tree differs between full and sparse checkouts after
|
|
|
|
|
# reset, the state of the index is the same.
|
|
|
|
|
test_expect_success 'reset with pathspecs outside sparse definition' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
test_all_match git checkout -b reset-test base &&
|
|
|
|
|
|
|
|
|
|
test_sparse_match git reset update-folder1 -- folder1 &&
|
|
|
|
|
git -C full-checkout reset update-folder1 -- folder1 &&
|
|
|
|
|
test_sparse_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git rev-parse HEAD:folder1 &&
|
|
|
|
|
|
|
|
|
|
test_sparse_match git reset update-folder2 -- folder2/a &&
|
|
|
|
|
git -C full-checkout reset update-folder2 -- folder2/a &&
|
|
|
|
|
test_sparse_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git rev-parse HEAD:folder2/a
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'reset with wildcard pathspec' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
test_all_match git reset update-deep -- deep\* &&
|
|
|
|
|
test_all_match git ls-files -s -- deep &&
|
|
|
|
|
|
|
|
|
|
test_all_match git reset deepest -- deep\*\*\* &&
|
|
|
|
|
test_all_match git ls-files -s -- deep &&
|
|
|
|
|
|
|
|
|
|
# The following `git reset`s result in updating the index on files with
|
|
|
|
|
# `skip-worktree` enabled. To avoid failing due to discrepencies in reported
|
|
|
|
|
# "modified" files, `test_sparse_match` reset is performed separately from
|
|
|
|
|
# "full-checkout" reset, then the index contents of all repos are verified.
|
|
|
|
|
|
|
|
|
|
test_sparse_match git reset update-folder1 -- \*/a &&
|
|
|
|
|
git -C full-checkout reset update-folder1 -- \*/a &&
|
|
|
|
|
test_all_match git ls-files -s -- deep/a folder1/a &&
|
|
|
|
|
|
|
|
|
|
test_sparse_match git reset update-folder2 -- folder\* &&
|
|
|
|
|
git -C full-checkout reset update-folder2 -- folder\* &&
|
|
|
|
|
test_all_match git ls-files -s -- folder10 folder1 folder2 &&
|
|
|
|
|
|
|
|
|
|
test_sparse_match git reset base -- folder1/\* &&
|
|
|
|
|
git -C full-checkout reset base -- folder1/\* &&
|
|
|
|
|
test_all_match git ls-files -s -- folder1
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
'
|
|
|
|
|
|
2021-09-08 13:23:59 +02:00
|
|
|
test_expect_success 'merge, cherry-pick, and rebase' '
|
2021-01-23 20:58:19 +01:00
|
|
|
init_repos &&
|
|
|
|
|
|
2021-10-16 11:07:09 +02:00
|
|
|
for OPERATION in "merge -m merge" cherry-pick "rebase --apply" "rebase --merge"
|
2021-09-08 13:23:59 +02:00
|
|
|
do
|
|
|
|
|
test_all_match git checkout -B temp update-deep &&
|
|
|
|
|
test_all_match git $OPERATION update-folder1 &&
|
|
|
|
|
test_all_match git rev-parse HEAD^{tree} &&
|
|
|
|
|
test_all_match git $OPERATION update-folder2 &&
|
|
|
|
|
test_all_match git rev-parse HEAD^{tree} || return 1
|
|
|
|
|
done
|
2021-01-23 20:58:19 +01:00
|
|
|
'
|
|
|
|
|
|
2021-09-24 17:39:08 +02:00
|
|
|
test_expect_success 'merge with conflict outside cone' '
|
2021-07-29 16:52:03 +02:00
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout -b merge-tip merge-left &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match test_must_fail git merge -m merge merge-right &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
# Resolve the conflict in different ways:
|
|
|
|
|
# 1. Revert to the base
|
|
|
|
|
test_all_match git checkout base -- deep/deeper2/a &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
# 2. Add the file with conflict markers
|
2021-09-24 17:39:07 +02:00
|
|
|
test_sparse_match test_must_fail git add folder1/a &&
|
|
|
|
|
grep "Disable or modify the sparsity rules" sparse-checkout-err &&
|
|
|
|
|
test_sparse_unstaged folder1/a &&
|
2021-09-24 17:39:08 +02:00
|
|
|
test_all_match git add --sparse folder1/a &&
|
2021-07-29 16:52:03 +02:00
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
# 3. Rename the file to another sparse filename and
|
|
|
|
|
# accept conflict markers as resolved content.
|
|
|
|
|
run_on_all mv folder2/a folder2/z &&
|
2021-09-24 17:39:07 +02:00
|
|
|
test_sparse_match test_must_fail git add folder2 &&
|
|
|
|
|
grep "Disable or modify the sparsity rules" sparse-checkout-err &&
|
|
|
|
|
test_sparse_unstaged folder2/z &&
|
2021-09-24 17:39:08 +02:00
|
|
|
test_all_match git add --sparse folder2 &&
|
2021-07-29 16:52:03 +02:00
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
test_all_match git merge --continue &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git rev-parse HEAD^{tree}
|
|
|
|
|
'
|
|
|
|
|
|
2021-09-24 17:39:08 +02:00
|
|
|
test_expect_success 'cherry-pick/rebase with conflict outside cone' '
|
2021-09-08 13:24:01 +02:00
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
for OPERATION in cherry-pick rebase
|
|
|
|
|
do
|
|
|
|
|
test_all_match git checkout -B tip &&
|
|
|
|
|
test_all_match git reset --hard merge-left &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match test_must_fail git $OPERATION merge-right &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
# Resolve the conflict in different ways:
|
|
|
|
|
# 1. Revert to the base
|
|
|
|
|
test_all_match git checkout base -- deep/deeper2/a &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
# 2. Add the file with conflict markers
|
2021-09-24 17:39:06 +02:00
|
|
|
# NEEDSWORK: Even though the merge conflict removed the
|
|
|
|
|
# SKIP_WORKTREE bit from the index entry for folder1/a, we should
|
|
|
|
|
# warn that this is a problematic add.
|
2021-09-24 17:39:07 +02:00
|
|
|
test_sparse_match test_must_fail git add folder1/a &&
|
|
|
|
|
grep "Disable or modify the sparsity rules" sparse-checkout-err &&
|
|
|
|
|
test_sparse_unstaged folder1/a &&
|
2021-09-24 17:39:08 +02:00
|
|
|
test_all_match git add --sparse folder1/a &&
|
2021-09-08 13:24:01 +02:00
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
# 3. Rename the file to another sparse filename and
|
|
|
|
|
# accept conflict markers as resolved content.
|
2021-09-24 17:39:06 +02:00
|
|
|
# NEEDSWORK: This mode now fails, because folder2/z is
|
|
|
|
|
# outside of the sparse-checkout cone and does not match an
|
|
|
|
|
# existing index entry with the SKIP_WORKTREE bit cleared.
|
2021-09-08 13:24:01 +02:00
|
|
|
run_on_all mv folder2/a folder2/z &&
|
2021-09-24 17:39:07 +02:00
|
|
|
test_sparse_match test_must_fail git add folder2 &&
|
|
|
|
|
grep "Disable or modify the sparsity rules" sparse-checkout-err &&
|
|
|
|
|
test_sparse_unstaged folder2/z &&
|
2021-09-24 17:39:08 +02:00
|
|
|
test_all_match git add --sparse folder2 &&
|
2021-09-08 13:24:01 +02:00
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
test_all_match git $OPERATION --continue &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git rev-parse HEAD^{tree} || return 1
|
|
|
|
|
done
|
|
|
|
|
'
|
|
|
|
|
|
2021-01-23 20:58:19 +01:00
|
|
|
test_expect_success 'merge with outside renames' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
for type in out-to-out out-to-in in-to-out
|
|
|
|
|
do
|
|
|
|
|
test_all_match git reset --hard &&
|
|
|
|
|
test_all_match git checkout -f -b merge-$type update-deep &&
|
|
|
|
|
test_all_match git merge -m "$type" rename-$type &&
|
|
|
|
|
test_all_match git rev-parse HEAD^{tree} || return 1
|
|
|
|
|
done
|
|
|
|
|
'
|
|
|
|
|
|
sparse-index: skip indexes with unmerged entries
The sparse-index format is designed to be compatible with merge
conflicts, even those outside the sparse-checkout definition. The reason
is that when converting a full index to a sparse one, a cache entry with
nonzero stage will not be collapsed into a sparse directory entry.
However, this behavior was not tested, and a different behavior within
convert_to_sparse() fails in this scenario. Specifically,
cache_tree_update() will fail when unmerged entries exist.
convert_to_sparse_rec() uses the cache-tree data to recursively walk the
tree structure, but also to compute the OIDs used in the
sparse-directory entries.
Add an index scan to convert_to_sparse() that will detect if these merge
conflict entries exist and skip the conversion before trying to update
the cache-tree. This is marked as NEEDSWORK because this can be removed
with a suitable update to cache_tree_update() or a similar method that
can construct a cache-tree with invalid nodes, but still allow creating
the nodes necessary for creating sparse directory entries.
It is possible that in the future we will not need to make such an
update, since if we do not expand a sparse-index into a full one, this
conversion does not need to happen. Thus, this can be deferred until the
merge machinery is made to integrate with the sparse-index.
Reviewed-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-14 15:12:25 +02:00
|
|
|
# Sparse-index fails to convert the index in the
|
|
|
|
|
# final 'git cherry-pick' command.
|
|
|
|
|
test_expect_success 'cherry-pick with conflicts' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
write_script edit-conflict <<-\EOF &&
|
|
|
|
|
echo $1 >conflict
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout -b to-cherry-pick &&
|
|
|
|
|
run_on_all ../edit-conflict ABC &&
|
|
|
|
|
test_all_match git add conflict &&
|
|
|
|
|
test_all_match git commit -m "conflict to pick" &&
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout -B base HEAD~1 &&
|
|
|
|
|
run_on_all ../edit-conflict DEF &&
|
|
|
|
|
test_all_match git add conflict &&
|
|
|
|
|
test_all_match git commit -m "conflict in base" &&
|
|
|
|
|
|
|
|
|
|
test_all_match test_must_fail git cherry-pick to-cherry-pick
|
|
|
|
|
'
|
|
|
|
|
|
2021-01-23 20:58:19 +01:00
|
|
|
test_expect_success 'clean' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
echo bogus >>.gitignore &&
|
|
|
|
|
run_on_all cp ../.gitignore . &&
|
|
|
|
|
test_all_match git add .gitignore &&
|
2021-03-30 15:10:46 +02:00
|
|
|
test_all_match git commit -m "ignore bogus files" &&
|
2021-01-23 20:58:19 +01:00
|
|
|
|
|
|
|
|
run_on_sparse mkdir folder1 &&
|
|
|
|
|
run_on_all touch folder1/bogus &&
|
|
|
|
|
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git clean -f &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
test_sparse_match ls &&
|
|
|
|
|
test_sparse_match ls folder1 &&
|
2021-01-23 20:58:19 +01:00
|
|
|
|
|
|
|
|
test_all_match git clean -xf &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
test_sparse_match ls &&
|
|
|
|
|
test_sparse_match ls folder1 &&
|
2021-01-23 20:58:19 +01:00
|
|
|
|
|
|
|
|
test_all_match git clean -xdf &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
test_sparse_match ls &&
|
|
|
|
|
test_sparse_match ls folder1 &&
|
2021-01-23 20:58:19 +01:00
|
|
|
|
sparse-index: convert from full to sparse
If we have a full index, then we can convert it to a sparse index by
replacing directories outside of the sparse cone with sparse directory
entries. The convert_to_sparse() method does this, when the situation is
appropriate.
For now, we avoid converting the index to a sparse index if:
1. the index is split.
2. the index is already sparse.
3. sparse-checkout is disabled.
4. sparse-checkout does not use cone mode.
Finally, we currently limit the conversion to when the
GIT_TEST_SPARSE_INDEX environment variable is enabled. A mode using Git
config will be added in a later change.
The trickiest thing about this conversion is that we might not be able
to mark a directory as a sparse directory just because it is outside the
sparse cone. There might be unmerged files within that directory, so we
need to look for those. Also, if there is some strange reason why a file
is not marked with CE_SKIP_WORKTREE, then we should give up on
converting that directory. There is still hope that some of its
subdirectories might be able to convert to sparse, so we keep looking
deeper.
The conversion process is assisted by the cache-tree extension. This is
calculated from the full index if it does not already exist. We then
abandon the cache-tree as it no longer applies to the newly-sparse
index. Thus, this cache-tree will be recalculated in every
sparse-full-sparse round-trip until we integrate the cache-tree
extension with the sparse index.
Some Git commands use the index after writing it. For example, 'git add'
will update the index, then write it to disk, then read its entries to
report information. To keep the in-memory index in a full state after
writing, we re-expand it to a full one after the write. This is wasteful
for commands that only write the index and do not read from it again,
but that is only the case until we make those commands "sparse aware."
We can compare the behavior of the sparse-index in
t1092-sparse-checkout-compability.sh by using GIT_TEST_SPARSE_INDEX=1
when operating on the 'sparse-index' repo. We can also compare the two
sparse repos directly, such as comparing their indexes (when expanded to
full in the case of the 'sparse-index' repo). We also verify that the
index is actually populated with sparse directory entries.
The 'checkout and reset (mixed)' test is marked for failure when
comparing a sparse repo to a full repo, but we can compare the two
sparse-checkout cases directly to ensure that we are not changing the
behavior when using a sparse index.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:10:55 +02:00
|
|
|
test_sparse_match test_path_is_dir folder1
|
2021-01-23 20:58:19 +01:00
|
|
|
'
|
|
|
|
|
|
2021-03-30 15:10:56 +02:00
|
|
|
test_expect_success 'submodule handling' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
2021-09-24 17:39:06 +02:00
|
|
|
test_sparse_match git sparse-checkout add modules &&
|
2021-03-30 15:10:56 +02:00
|
|
|
test_all_match mkdir modules &&
|
|
|
|
|
test_all_match touch modules/a &&
|
|
|
|
|
test_all_match git add modules &&
|
|
|
|
|
test_all_match git commit -m "add modules directory" &&
|
|
|
|
|
|
|
|
|
|
run_on_all git submodule add "$(pwd)/initial-repo" modules/sub &&
|
|
|
|
|
test_all_match git commit -m "add submodule" &&
|
|
|
|
|
|
|
|
|
|
# having a submodule prevents "modules" from collapse
|
2021-09-24 17:39:06 +02:00
|
|
|
test_sparse_match git sparse-checkout set deep/deeper1 &&
|
2021-03-30 15:10:56 +02:00
|
|
|
test-tool -C sparse-index read-cache --table >cache &&
|
|
|
|
|
grep "100644 blob .* modules/a" cache &&
|
|
|
|
|
grep "160000 commit $(git -C initial-repo rev-parse HEAD) modules/sub" cache
|
|
|
|
|
'
|
|
|
|
|
|
2021-10-27 16:39:18 +02:00
|
|
|
# When working with a sparse index, some commands will need to expand the
|
|
|
|
|
# index to operate properly. If those commands also write the index back
|
|
|
|
|
# to disk, they need to convert the index to sparse before writing.
|
|
|
|
|
# This test verifies that both of these events are logged in trace2 logs.
|
2021-03-30 15:10:58 +02:00
|
|
|
test_expect_success 'sparse-index is expanded and converted back' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
2021-11-29 14:47:46 +01:00
|
|
|
GIT_TRACE2_EVENT="$(pwd)/trace2.txt" \
|
2021-10-27 16:39:18 +02:00
|
|
|
git -C sparse-index reset -- folder1/a &&
|
2021-03-30 15:11:00 +02:00
|
|
|
test_region index convert_to_sparse trace2.txt &&
|
2021-07-14 15:12:37 +02:00
|
|
|
test_region index ensure_full_index trace2.txt
|
|
|
|
|
'
|
2021-03-30 15:11:00 +02:00
|
|
|
|
2021-11-23 01:20:33 +01:00
|
|
|
test_expect_success 'index.sparse disabled inline uses full index' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
# When index.sparse is disabled inline with `git status`, the
|
|
|
|
|
# index is expanded at the beginning of the execution then never
|
|
|
|
|
# converted back to sparse. It is then written to disk as a full index.
|
|
|
|
|
rm -f trace2.txt &&
|
|
|
|
|
GIT_TRACE2_EVENT="$(pwd)/trace2.txt" GIT_TRACE2_EVENT_NESTING=10 \
|
|
|
|
|
git -C sparse-index -c index.sparse=false status &&
|
|
|
|
|
! test_region index convert_to_sparse trace2.txt &&
|
|
|
|
|
test_region index ensure_full_index trace2.txt &&
|
|
|
|
|
|
|
|
|
|
# Since index.sparse is set to true at a repo level, the index
|
|
|
|
|
# is converted from full to sparse when read, then never expanded
|
|
|
|
|
# over the course of `git status`. It is written to disk as a sparse
|
|
|
|
|
# index.
|
|
|
|
|
rm -f trace2.txt &&
|
|
|
|
|
GIT_TRACE2_EVENT="$(pwd)/trace2.txt" GIT_TRACE2_EVENT_NESTING=10 \
|
|
|
|
|
git -C sparse-index status &&
|
|
|
|
|
test_region index convert_to_sparse trace2.txt &&
|
|
|
|
|
! test_region index ensure_full_index trace2.txt &&
|
|
|
|
|
|
|
|
|
|
# Now that the index has been written to disk as sparse, it is not
|
|
|
|
|
# converted to sparse (or expanded to full) when read by `git status`.
|
|
|
|
|
rm -f trace2.txt &&
|
|
|
|
|
GIT_TRACE2_EVENT="$(pwd)/trace2.txt" GIT_TRACE2_EVENT_NESTING=10 \
|
|
|
|
|
git -C sparse-index status &&
|
|
|
|
|
! test_region index convert_to_sparse trace2.txt &&
|
|
|
|
|
! test_region index ensure_full_index trace2.txt
|
|
|
|
|
'
|
|
|
|
|
|
2021-06-29 04:13:04 +02:00
|
|
|
ensure_not_expanded () {
|
2021-07-14 15:12:37 +02:00
|
|
|
rm -f trace2.txt &&
|
|
|
|
|
echo >>sparse-index/untracked.txt &&
|
2021-09-08 13:23:58 +02:00
|
|
|
|
|
|
|
|
if test "$1" = "!"
|
|
|
|
|
then
|
|
|
|
|
shift &&
|
|
|
|
|
test_must_fail env \
|
2021-11-29 14:47:46 +01:00
|
|
|
GIT_TRACE2_EVENT="$(pwd)/trace2.txt" \
|
2021-09-08 13:23:58 +02:00
|
|
|
git -C sparse-index "$@" || return 1
|
|
|
|
|
else
|
2021-11-29 14:47:46 +01:00
|
|
|
GIT_TRACE2_EVENT="$(pwd)/trace2.txt" \
|
2021-09-08 13:23:58 +02:00
|
|
|
git -C sparse-index "$@" || return 1
|
|
|
|
|
fi &&
|
2021-07-14 15:12:37 +02:00
|
|
|
test_region ! index ensure_full_index trace2.txt
|
2021-06-29 04:13:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test_expect_success 'sparse-index is not expanded' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
ensure_not_expanded status &&
|
|
|
|
|
ensure_not_expanded commit --allow-empty -m empty &&
|
|
|
|
|
echo >>sparse-index/a &&
|
|
|
|
|
ensure_not_expanded commit -a -m a &&
|
|
|
|
|
echo >>sparse-index/a &&
|
|
|
|
|
ensure_not_expanded commit --include a -m a &&
|
|
|
|
|
echo >>sparse-index/deep/deeper1/a &&
|
2021-06-29 04:13:06 +02:00
|
|
|
ensure_not_expanded commit --include deep/deeper1/a -m deeper &&
|
|
|
|
|
ensure_not_expanded checkout rename-out-to-out &&
|
|
|
|
|
ensure_not_expanded checkout - &&
|
|
|
|
|
ensure_not_expanded switch rename-out-to-out &&
|
|
|
|
|
ensure_not_expanded switch - &&
|
2021-11-29 16:52:41 +01:00
|
|
|
ensure_not_expanded reset --hard &&
|
2021-06-29 04:13:06 +02:00
|
|
|
ensure_not_expanded checkout rename-out-to-out -- deep/deeper1 &&
|
2021-11-29 16:52:41 +01:00
|
|
|
ensure_not_expanded reset --hard &&
|
2021-07-29 16:52:04 +02:00
|
|
|
ensure_not_expanded restore -s rename-out-to-out -- deep/deeper1 &&
|
|
|
|
|
|
|
|
|
|
echo >>sparse-index/README.md &&
|
|
|
|
|
ensure_not_expanded add -A &&
|
|
|
|
|
echo >>sparse-index/extra.txt &&
|
2021-07-29 16:52:05 +02:00
|
|
|
ensure_not_expanded add extra.txt &&
|
|
|
|
|
echo >>sparse-index/untracked.txt &&
|
2021-09-08 13:23:57 +02:00
|
|
|
ensure_not_expanded add . &&
|
|
|
|
|
|
2021-11-29 16:52:41 +01:00
|
|
|
for ref in update-deep update-folder1 update-folder2 update-deep
|
|
|
|
|
do
|
|
|
|
|
echo >>sparse-index/README.md &&
|
|
|
|
|
ensure_not_expanded reset --hard $ref || return 1
|
|
|
|
|
done &&
|
|
|
|
|
|
2021-11-29 16:52:42 +01:00
|
|
|
ensure_not_expanded reset --mixed base &&
|
2021-11-29 16:52:41 +01:00
|
|
|
ensure_not_expanded reset --hard update-deep &&
|
|
|
|
|
ensure_not_expanded reset --keep base &&
|
|
|
|
|
ensure_not_expanded reset --merge update-deep &&
|
|
|
|
|
ensure_not_expanded reset --hard &&
|
|
|
|
|
|
2021-11-29 16:52:42 +01:00
|
|
|
ensure_not_expanded reset base -- deep/a &&
|
|
|
|
|
ensure_not_expanded reset base -- nonexistent-file &&
|
|
|
|
|
ensure_not_expanded reset deepest -- deep &&
|
|
|
|
|
|
|
|
|
|
# Although folder1 is outside the sparse definition, it exists as a
|
|
|
|
|
# directory entry in the index, so the pathspec will not force the
|
|
|
|
|
# index to be expanded.
|
|
|
|
|
ensure_not_expanded reset deepest -- folder1 &&
|
|
|
|
|
ensure_not_expanded reset deepest -- folder1/ &&
|
|
|
|
|
|
|
|
|
|
# Wildcard identifies only in-cone files, no index expansion
|
|
|
|
|
ensure_not_expanded reset deepest -- deep/\* &&
|
|
|
|
|
|
|
|
|
|
# Wildcard identifies only full sparse directories, no index expansion
|
|
|
|
|
ensure_not_expanded reset deepest -- folder\* &&
|
|
|
|
|
|
2021-09-08 13:23:57 +02:00
|
|
|
ensure_not_expanded checkout -f update-deep &&
|
|
|
|
|
test_config -C sparse-index pull.twohead ort &&
|
|
|
|
|
(
|
|
|
|
|
sane_unset GIT_TEST_MERGE_ALGORITHM &&
|
2021-09-08 13:24:01 +02:00
|
|
|
for OPERATION in "merge -m merge" cherry-pick rebase
|
|
|
|
|
do
|
|
|
|
|
ensure_not_expanded merge -m merge update-folder1 &&
|
|
|
|
|
ensure_not_expanded merge -m merge update-folder2 || return 1
|
|
|
|
|
done
|
2021-09-08 13:23:57 +02:00
|
|
|
)
|
2021-03-30 15:10:58 +02:00
|
|
|
'
|
|
|
|
|
|
2021-09-08 13:23:58 +02:00
|
|
|
test_expect_success 'sparse-index is not expanded: merge conflict in cone' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
for side in right left
|
|
|
|
|
do
|
|
|
|
|
git -C sparse-index checkout -b expand-$side base &&
|
|
|
|
|
echo $side >sparse-index/deep/a &&
|
|
|
|
|
git -C sparse-index commit -a -m "$side" || return 1
|
|
|
|
|
done &&
|
|
|
|
|
|
|
|
|
|
(
|
|
|
|
|
sane_unset GIT_TEST_MERGE_ALGORITHM &&
|
|
|
|
|
git -C sparse-index config pull.twohead ort &&
|
|
|
|
|
ensure_not_expanded ! merge -m merged expand-right
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2021-12-06 16:56:00 +01:00
|
|
|
test_expect_success 'sparse index is not expanded: diff' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
write_script edit-contents <<-\EOF &&
|
|
|
|
|
echo text >>$1
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
# Add file within cone
|
|
|
|
|
test_sparse_match git sparse-checkout set deep &&
|
|
|
|
|
run_on_all ../edit-contents deep/testfile &&
|
|
|
|
|
test_all_match git add deep/testfile &&
|
|
|
|
|
run_on_all ../edit-contents deep/testfile &&
|
|
|
|
|
|
|
|
|
|
test_all_match git diff &&
|
|
|
|
|
test_all_match git diff --cached &&
|
|
|
|
|
ensure_not_expanded diff &&
|
|
|
|
|
ensure_not_expanded diff --cached &&
|
|
|
|
|
|
|
|
|
|
# Add file outside cone
|
|
|
|
|
test_all_match git reset --hard &&
|
|
|
|
|
run_on_all mkdir newdirectory &&
|
|
|
|
|
run_on_all ../edit-contents newdirectory/testfile &&
|
|
|
|
|
test_sparse_match git sparse-checkout set newdirectory &&
|
|
|
|
|
test_all_match git add newdirectory/testfile &&
|
|
|
|
|
run_on_all ../edit-contents newdirectory/testfile &&
|
|
|
|
|
test_sparse_match git sparse-checkout set &&
|
|
|
|
|
|
|
|
|
|
test_all_match git diff &&
|
|
|
|
|
test_all_match git diff --cached &&
|
|
|
|
|
ensure_not_expanded diff &&
|
|
|
|
|
ensure_not_expanded diff --cached &&
|
|
|
|
|
|
|
|
|
|
# Merge conflict outside cone
|
|
|
|
|
# The sparse checkout will report a warning that is not in the
|
|
|
|
|
# full checkout, so we use `run_on_all` instead of
|
|
|
|
|
# `test_all_match`
|
|
|
|
|
run_on_all git reset --hard &&
|
|
|
|
|
test_all_match git checkout merge-left &&
|
|
|
|
|
test_all_match test_must_fail git merge merge-right &&
|
|
|
|
|
|
|
|
|
|
test_all_match git diff &&
|
|
|
|
|
test_all_match git diff --cached &&
|
|
|
|
|
ensure_not_expanded diff &&
|
|
|
|
|
ensure_not_expanded diff --cached
|
|
|
|
|
'
|
|
|
|
|
|
2021-12-06 16:56:01 +01:00
|
|
|
test_expect_success 'sparse index is not expanded: blame' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
for file in a \
|
|
|
|
|
deep/a \
|
|
|
|
|
deep/deeper1/a \
|
|
|
|
|
deep/deeper1/deepest/a
|
|
|
|
|
do
|
|
|
|
|
ensure_not_expanded blame $file
|
|
|
|
|
done
|
|
|
|
|
'
|
|
|
|
|
|
2021-12-22 15:20:52 +01:00
|
|
|
test_expect_success 'sparse index is not expanded: fetch/pull' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
git -C sparse-index remote add full "file://$(pwd)/full-checkout" &&
|
|
|
|
|
ensure_not_expanded fetch full &&
|
|
|
|
|
git -C full-checkout commit --allow-empty -m "for pull merge" &&
|
|
|
|
|
git -C sparse-index commit --allow-empty -m "for pull merge" &&
|
|
|
|
|
ensure_not_expanded pull full base
|
|
|
|
|
'
|
|
|
|
|
|
2021-07-14 15:12:40 +02:00
|
|
|
# NEEDSWORK: a sparse-checkout behaves differently from a full checkout
|
|
|
|
|
# in this scenario, but it shouldn't.
|
2021-07-14 15:12:38 +02:00
|
|
|
test_expect_success 'reset mixed and checkout orphan' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout rename-out-to-in &&
|
|
|
|
|
|
|
|
|
|
# Sparse checkouts do not agree with full checkouts about
|
|
|
|
|
# how to report a directory/file conflict during a reset.
|
|
|
|
|
# This command would fail with test_all_match because the
|
|
|
|
|
# full checkout reports "T folder1/0/1" while a sparse
|
|
|
|
|
# checkout reports "D folder1/0/1". This matches because
|
|
|
|
|
# the sparse checkouts skip "adding" the other side of
|
|
|
|
|
# the conflict.
|
|
|
|
|
test_sparse_match git reset --mixed HEAD~1 &&
|
|
|
|
|
test_sparse_match test-tool read-cache --table --expand &&
|
|
|
|
|
test_sparse_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
# At this point, sparse-checkouts behave differently
|
|
|
|
|
# from the full-checkout.
|
|
|
|
|
test_sparse_match git checkout --orphan new-branch &&
|
|
|
|
|
test_sparse_match test-tool read-cache --table --expand &&
|
|
|
|
|
test_sparse_match git status --porcelain=v2
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'add everything with deep new file' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
run_on_sparse git sparse-checkout set deep/deeper1/deepest &&
|
|
|
|
|
|
|
|
|
|
run_on_all touch deep/deeper1/x &&
|
|
|
|
|
test_all_match git add . &&
|
|
|
|
|
test_all_match git status --porcelain=v2
|
|
|
|
|
'
|
|
|
|
|
|
t1092: document bad 'git checkout' behavior
Add new branches to the test repo that demonstrate directory/file
conflicts in different ways. Since the directory 'folder1/' has
adjacent files 'folder1-', 'folder1.txt', and 'folder10' it causes
searches for 'folder1/' to land in a different place in the index than a
search for 'folder1'. This causes a change in behavior when working with
the df-conflict-1 and df-conflict-2 branches, whose only difference is
that the first uses 'folder1' as the conflict and the other uses
'folder2' which does not have these adjacent files.
We can extend two tests that compare the behavior across different 'git
checkout' commands, and we see already that the behavior will be
different in some cases and not in others. The difference between the
two test loops is that one uses 'git reset --hard' between iterations.
Further, we isolate the behavior of creating a staged change within a
directory and then checking out a branch where that directory is
replaced with a file. A full checkout behaves differently across these
two cases, while a sparse-checkout cone behaves consistently. In both
cases, the behavior is wrong. In one case, the staged change is dropped
entirely. The other case the staged change is kept, replacing the file
at that location, but none of the other files in the directory are kept.
Likely, the correct behavior in this case is to reject the checkout and
report the conflict, leaving HEAD in its previous location. None of the
cases behave this way currently. Use comments to demonstrate that the
tested behavior is only a documentation of the current, incorrect
behavior to ensure we do not _accidentally_ change it. Instead, we would
prefer to change it on purpose with a future change.
At this point, the sparse-index does not handle these 'git checkout'
commands correctly. Or rather, it _does_ reject the 'git checkout' when
we have the staged change, but for the wrong reason. It also rejects the
'git checkout' commands when there is no staged change and we want to
replace a directory with a file. A fix for that unstaged case will
follow in the next change, but that will make the sparse-index agree
with the full checkout case in these documented incorrect behaviors.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:40 +02:00
|
|
|
# NEEDSWORK: 'git checkout' behaves incorrectly in the case of
|
|
|
|
|
# directory/file conflicts, even without sparse-checkout. Use this
|
|
|
|
|
# test only as a documentation of the incorrect behavior, not a
|
|
|
|
|
# measure of how it _should_ behave.
|
|
|
|
|
test_expect_success 'checkout behaves oddly with df-conflict-1' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
test_sparse_match git sparse-checkout disable &&
|
|
|
|
|
|
|
|
|
|
write_script edit-content <<-\EOF &&
|
|
|
|
|
echo content >>folder1/larger-content
|
|
|
|
|
git add folder1
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
run_on_all ../edit-content &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
git -C sparse-checkout sparse-checkout init --cone &&
|
|
|
|
|
git -C sparse-index sparse-checkout init --cone --sparse-index &&
|
|
|
|
|
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
# This checkout command should fail, because we have a staged
|
|
|
|
|
# change to folder1/larger-content, but the destination changes
|
|
|
|
|
# folder1 to a file.
|
|
|
|
|
git -C full-checkout checkout df-conflict-1 \
|
|
|
|
|
1>full-checkout-out \
|
|
|
|
|
2>full-checkout-err &&
|
|
|
|
|
git -C sparse-checkout checkout df-conflict-1 \
|
|
|
|
|
1>sparse-checkout-out \
|
|
|
|
|
2>sparse-checkout-err &&
|
unpack-trees: resolve sparse-directory/file conflicts
When running unpack_trees() with a sparse index, we attempt to operate
on the index without expanding the sparse directory entries. Thus, we
operate by manipulating entire directories and passing them to the
unpack function. In the case of the 'git checkout' command, this is the
twoway_merge() function.
There are several cases in twoway_merge() that handle different
situations. One new one to add is the case of a directory/file conflict
where the directory is sparse. Before the sparse index, such a conflict
would appear as a list of file additions and deletions. Now,
twoway_merge() initializes 'current', 'oldtree', and 'newtree' from
src[0], src[1], and src[2], then sets 'oldtree' to NULL because it is
equal to the df_conflict_entry. The way to determine that we have a
directory/file conflict is to test that 'current' and 'newtree' disagree
on being sparse directory entries.
When we are in this case, we want to resolve the situation by calling
merged_entry(). This allows replacing the 'current' entry with the
'newtree' entry. This is important for cases where we want to run 'git
checkout' across the conflict and have the new HEAD represent the new
file type at that path. The first NEEDSWORK comment dropped in t1092
demonstrates this necessary behavior.
However, we still are in a confusing state when 'current' corresponds to
a staged change within a sparse directory that is not present at HEAD.
This should be atypical, because it requires adding a change outside of
the sparse-checkout cone, but it is possible. Since we are unable to
determine that this is a staged change within twoway_merge(), we cannot
add a case to reject the merge at this point. I believe this is due to
the use of df_conflict_entry in the place of 'oldtree' instead of using
the valud at HEAD, which would provide some perspective to this
decision. Any change that would allow this differentiation for staged
entries would need to involve information further up in unpack_trees().
That work should be done, sometime, because we are further confusing the
behavior of a directory/file conflict when staging a change in the
directory. The two cases 'checkout behaves oddly with df-conflict-?' in
t1092 demonstrate that even without a sparse-checkout, Git is not
consistent in its behavior. Neither of the two options seems correct,
either. This change makes the sparse-index behave differently than the
typcial sparse-checkout case, but it does match the full checkout
behavior in the df-conflict-2 case.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:41 +02:00
|
|
|
git -C sparse-index checkout df-conflict-1 \
|
t1092: document bad 'git checkout' behavior
Add new branches to the test repo that demonstrate directory/file
conflicts in different ways. Since the directory 'folder1/' has
adjacent files 'folder1-', 'folder1.txt', and 'folder10' it causes
searches for 'folder1/' to land in a different place in the index than a
search for 'folder1'. This causes a change in behavior when working with
the df-conflict-1 and df-conflict-2 branches, whose only difference is
that the first uses 'folder1' as the conflict and the other uses
'folder2' which does not have these adjacent files.
We can extend two tests that compare the behavior across different 'git
checkout' commands, and we see already that the behavior will be
different in some cases and not in others. The difference between the
two test loops is that one uses 'git reset --hard' between iterations.
Further, we isolate the behavior of creating a staged change within a
directory and then checking out a branch where that directory is
replaced with a file. A full checkout behaves differently across these
two cases, while a sparse-checkout cone behaves consistently. In both
cases, the behavior is wrong. In one case, the staged change is dropped
entirely. The other case the staged change is kept, replacing the file
at that location, but none of the other files in the directory are kept.
Likely, the correct behavior in this case is to reject the checkout and
report the conflict, leaving HEAD in its previous location. None of the
cases behave this way currently. Use comments to demonstrate that the
tested behavior is only a documentation of the current, incorrect
behavior to ensure we do not _accidentally_ change it. Instead, we would
prefer to change it on purpose with a future change.
At this point, the sparse-index does not handle these 'git checkout'
commands correctly. Or rather, it _does_ reject the 'git checkout' when
we have the staged change, but for the wrong reason. It also rejects the
'git checkout' commands when there is no staged change and we want to
replace a directory with a file. A fix for that unstaged case will
follow in the next change, but that will make the sparse-index agree
with the full checkout case in these documented incorrect behaviors.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:40 +02:00
|
|
|
1>sparse-index-out \
|
|
|
|
|
2>sparse-index-err &&
|
|
|
|
|
|
|
|
|
|
# Instead, the checkout deletes the folder1 file and adds the
|
|
|
|
|
# folder1/larger-content file, leaving all other paths that were
|
|
|
|
|
# in folder1/ as deleted (without any warning).
|
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
D folder1
|
|
|
|
|
A folder1/larger-content
|
|
|
|
|
EOF
|
|
|
|
|
test_cmp expect full-checkout-out &&
|
|
|
|
|
test_cmp expect sparse-checkout-out &&
|
|
|
|
|
|
unpack-trees: resolve sparse-directory/file conflicts
When running unpack_trees() with a sparse index, we attempt to operate
on the index without expanding the sparse directory entries. Thus, we
operate by manipulating entire directories and passing them to the
unpack function. In the case of the 'git checkout' command, this is the
twoway_merge() function.
There are several cases in twoway_merge() that handle different
situations. One new one to add is the case of a directory/file conflict
where the directory is sparse. Before the sparse index, such a conflict
would appear as a list of file additions and deletions. Now,
twoway_merge() initializes 'current', 'oldtree', and 'newtree' from
src[0], src[1], and src[2], then sets 'oldtree' to NULL because it is
equal to the df_conflict_entry. The way to determine that we have a
directory/file conflict is to test that 'current' and 'newtree' disagree
on being sparse directory entries.
When we are in this case, we want to resolve the situation by calling
merged_entry(). This allows replacing the 'current' entry with the
'newtree' entry. This is important for cases where we want to run 'git
checkout' across the conflict and have the new HEAD represent the new
file type at that path. The first NEEDSWORK comment dropped in t1092
demonstrates this necessary behavior.
However, we still are in a confusing state when 'current' corresponds to
a staged change within a sparse directory that is not present at HEAD.
This should be atypical, because it requires adding a change outside of
the sparse-checkout cone, but it is possible. Since we are unable to
determine that this is a staged change within twoway_merge(), we cannot
add a case to reject the merge at this point. I believe this is due to
the use of df_conflict_entry in the place of 'oldtree' instead of using
the valud at HEAD, which would provide some perspective to this
decision. Any change that would allow this differentiation for staged
entries would need to involve information further up in unpack_trees().
That work should be done, sometime, because we are further confusing the
behavior of a directory/file conflict when staging a change in the
directory. The two cases 'checkout behaves oddly with df-conflict-?' in
t1092 demonstrate that even without a sparse-checkout, Git is not
consistent in its behavior. Neither of the two options seems correct,
either. This change makes the sparse-index behave differently than the
typcial sparse-checkout case, but it does match the full checkout
behavior in the df-conflict-2 case.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:41 +02:00
|
|
|
# The sparse-index reports no output
|
|
|
|
|
test_must_be_empty sparse-index-out &&
|
|
|
|
|
|
t1092: document bad 'git checkout' behavior
Add new branches to the test repo that demonstrate directory/file
conflicts in different ways. Since the directory 'folder1/' has
adjacent files 'folder1-', 'folder1.txt', and 'folder10' it causes
searches for 'folder1/' to land in a different place in the index than a
search for 'folder1'. This causes a change in behavior when working with
the df-conflict-1 and df-conflict-2 branches, whose only difference is
that the first uses 'folder1' as the conflict and the other uses
'folder2' which does not have these adjacent files.
We can extend two tests that compare the behavior across different 'git
checkout' commands, and we see already that the behavior will be
different in some cases and not in others. The difference between the
two test loops is that one uses 'git reset --hard' between iterations.
Further, we isolate the behavior of creating a staged change within a
directory and then checking out a branch where that directory is
replaced with a file. A full checkout behaves differently across these
two cases, while a sparse-checkout cone behaves consistently. In both
cases, the behavior is wrong. In one case, the staged change is dropped
entirely. The other case the staged change is kept, replacing the file
at that location, but none of the other files in the directory are kept.
Likely, the correct behavior in this case is to reject the checkout and
report the conflict, leaving HEAD in its previous location. None of the
cases behave this way currently. Use comments to demonstrate that the
tested behavior is only a documentation of the current, incorrect
behavior to ensure we do not _accidentally_ change it. Instead, we would
prefer to change it on purpose with a future change.
At this point, the sparse-index does not handle these 'git checkout'
commands correctly. Or rather, it _does_ reject the 'git checkout' when
we have the staged change, but for the wrong reason. It also rejects the
'git checkout' commands when there is no staged change and we want to
replace a directory with a file. A fix for that unstaged case will
follow in the next change, but that will make the sparse-index agree
with the full checkout case in these documented incorrect behaviors.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:40 +02:00
|
|
|
# stderr: Switched to branch df-conflict-1
|
unpack-trees: resolve sparse-directory/file conflicts
When running unpack_trees() with a sparse index, we attempt to operate
on the index without expanding the sparse directory entries. Thus, we
operate by manipulating entire directories and passing them to the
unpack function. In the case of the 'git checkout' command, this is the
twoway_merge() function.
There are several cases in twoway_merge() that handle different
situations. One new one to add is the case of a directory/file conflict
where the directory is sparse. Before the sparse index, such a conflict
would appear as a list of file additions and deletions. Now,
twoway_merge() initializes 'current', 'oldtree', and 'newtree' from
src[0], src[1], and src[2], then sets 'oldtree' to NULL because it is
equal to the df_conflict_entry. The way to determine that we have a
directory/file conflict is to test that 'current' and 'newtree' disagree
on being sparse directory entries.
When we are in this case, we want to resolve the situation by calling
merged_entry(). This allows replacing the 'current' entry with the
'newtree' entry. This is important for cases where we want to run 'git
checkout' across the conflict and have the new HEAD represent the new
file type at that path. The first NEEDSWORK comment dropped in t1092
demonstrates this necessary behavior.
However, we still are in a confusing state when 'current' corresponds to
a staged change within a sparse directory that is not present at HEAD.
This should be atypical, because it requires adding a change outside of
the sparse-checkout cone, but it is possible. Since we are unable to
determine that this is a staged change within twoway_merge(), we cannot
add a case to reject the merge at this point. I believe this is due to
the use of df_conflict_entry in the place of 'oldtree' instead of using
the valud at HEAD, which would provide some perspective to this
decision. Any change that would allow this differentiation for staged
entries would need to involve information further up in unpack_trees().
That work should be done, sometime, because we are further confusing the
behavior of a directory/file conflict when staging a change in the
directory. The two cases 'checkout behaves oddly with df-conflict-?' in
t1092 demonstrate that even without a sparse-checkout, Git is not
consistent in its behavior. Neither of the two options seems correct,
either. This change makes the sparse-index behave differently than the
typcial sparse-checkout case, but it does match the full checkout
behavior in the df-conflict-2 case.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:41 +02:00
|
|
|
test_cmp full-checkout-err sparse-checkout-err &&
|
t1092: document bad 'git checkout' behavior
Add new branches to the test repo that demonstrate directory/file
conflicts in different ways. Since the directory 'folder1/' has
adjacent files 'folder1-', 'folder1.txt', and 'folder10' it causes
searches for 'folder1/' to land in a different place in the index than a
search for 'folder1'. This causes a change in behavior when working with
the df-conflict-1 and df-conflict-2 branches, whose only difference is
that the first uses 'folder1' as the conflict and the other uses
'folder2' which does not have these adjacent files.
We can extend two tests that compare the behavior across different 'git
checkout' commands, and we see already that the behavior will be
different in some cases and not in others. The difference between the
two test loops is that one uses 'git reset --hard' between iterations.
Further, we isolate the behavior of creating a staged change within a
directory and then checking out a branch where that directory is
replaced with a file. A full checkout behaves differently across these
two cases, while a sparse-checkout cone behaves consistently. In both
cases, the behavior is wrong. In one case, the staged change is dropped
entirely. The other case the staged change is kept, replacing the file
at that location, but none of the other files in the directory are kept.
Likely, the correct behavior in this case is to reject the checkout and
report the conflict, leaving HEAD in its previous location. None of the
cases behave this way currently. Use comments to demonstrate that the
tested behavior is only a documentation of the current, incorrect
behavior to ensure we do not _accidentally_ change it. Instead, we would
prefer to change it on purpose with a future change.
At this point, the sparse-index does not handle these 'git checkout'
commands correctly. Or rather, it _does_ reject the 'git checkout' when
we have the staged change, but for the wrong reason. It also rejects the
'git checkout' commands when there is no staged change and we want to
replace a directory with a file. A fix for that unstaged case will
follow in the next change, but that will make the sparse-index agree
with the full checkout case in these documented incorrect behaviors.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:40 +02:00
|
|
|
test_cmp full-checkout-err sparse-checkout-err
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
# NEEDSWORK: 'git checkout' behaves incorrectly in the case of
|
|
|
|
|
# directory/file conflicts, even without sparse-checkout. Use this
|
|
|
|
|
# test only as a documentation of the incorrect behavior, not a
|
|
|
|
|
# measure of how it _should_ behave.
|
|
|
|
|
test_expect_success 'checkout behaves oddly with df-conflict-2' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
test_sparse_match git sparse-checkout disable &&
|
|
|
|
|
|
|
|
|
|
write_script edit-content <<-\EOF &&
|
|
|
|
|
echo content >>folder2/larger-content
|
|
|
|
|
git add folder2
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
run_on_all ../edit-content &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
git -C sparse-checkout sparse-checkout init --cone &&
|
|
|
|
|
git -C sparse-index sparse-checkout init --cone --sparse-index &&
|
|
|
|
|
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
|
|
|
|
|
# This checkout command should fail, because we have a staged
|
|
|
|
|
# change to folder1/larger-content, but the destination changes
|
|
|
|
|
# folder1 to a file.
|
|
|
|
|
git -C full-checkout checkout df-conflict-2 \
|
|
|
|
|
1>full-checkout-out \
|
|
|
|
|
2>full-checkout-err &&
|
|
|
|
|
git -C sparse-checkout checkout df-conflict-2 \
|
|
|
|
|
1>sparse-checkout-out \
|
|
|
|
|
2>sparse-checkout-err &&
|
unpack-trees: resolve sparse-directory/file conflicts
When running unpack_trees() with a sparse index, we attempt to operate
on the index without expanding the sparse directory entries. Thus, we
operate by manipulating entire directories and passing them to the
unpack function. In the case of the 'git checkout' command, this is the
twoway_merge() function.
There are several cases in twoway_merge() that handle different
situations. One new one to add is the case of a directory/file conflict
where the directory is sparse. Before the sparse index, such a conflict
would appear as a list of file additions and deletions. Now,
twoway_merge() initializes 'current', 'oldtree', and 'newtree' from
src[0], src[1], and src[2], then sets 'oldtree' to NULL because it is
equal to the df_conflict_entry. The way to determine that we have a
directory/file conflict is to test that 'current' and 'newtree' disagree
on being sparse directory entries.
When we are in this case, we want to resolve the situation by calling
merged_entry(). This allows replacing the 'current' entry with the
'newtree' entry. This is important for cases where we want to run 'git
checkout' across the conflict and have the new HEAD represent the new
file type at that path. The first NEEDSWORK comment dropped in t1092
demonstrates this necessary behavior.
However, we still are in a confusing state when 'current' corresponds to
a staged change within a sparse directory that is not present at HEAD.
This should be atypical, because it requires adding a change outside of
the sparse-checkout cone, but it is possible. Since we are unable to
determine that this is a staged change within twoway_merge(), we cannot
add a case to reject the merge at this point. I believe this is due to
the use of df_conflict_entry in the place of 'oldtree' instead of using
the valud at HEAD, which would provide some perspective to this
decision. Any change that would allow this differentiation for staged
entries would need to involve information further up in unpack_trees().
That work should be done, sometime, because we are further confusing the
behavior of a directory/file conflict when staging a change in the
directory. The two cases 'checkout behaves oddly with df-conflict-?' in
t1092 demonstrate that even without a sparse-checkout, Git is not
consistent in its behavior. Neither of the two options seems correct,
either. This change makes the sparse-index behave differently than the
typcial sparse-checkout case, but it does match the full checkout
behavior in the df-conflict-2 case.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:41 +02:00
|
|
|
git -C sparse-index checkout df-conflict-2 \
|
t1092: document bad 'git checkout' behavior
Add new branches to the test repo that demonstrate directory/file
conflicts in different ways. Since the directory 'folder1/' has
adjacent files 'folder1-', 'folder1.txt', and 'folder10' it causes
searches for 'folder1/' to land in a different place in the index than a
search for 'folder1'. This causes a change in behavior when working with
the df-conflict-1 and df-conflict-2 branches, whose only difference is
that the first uses 'folder1' as the conflict and the other uses
'folder2' which does not have these adjacent files.
We can extend two tests that compare the behavior across different 'git
checkout' commands, and we see already that the behavior will be
different in some cases and not in others. The difference between the
two test loops is that one uses 'git reset --hard' between iterations.
Further, we isolate the behavior of creating a staged change within a
directory and then checking out a branch where that directory is
replaced with a file. A full checkout behaves differently across these
two cases, while a sparse-checkout cone behaves consistently. In both
cases, the behavior is wrong. In one case, the staged change is dropped
entirely. The other case the staged change is kept, replacing the file
at that location, but none of the other files in the directory are kept.
Likely, the correct behavior in this case is to reject the checkout and
report the conflict, leaving HEAD in its previous location. None of the
cases behave this way currently. Use comments to demonstrate that the
tested behavior is only a documentation of the current, incorrect
behavior to ensure we do not _accidentally_ change it. Instead, we would
prefer to change it on purpose with a future change.
At this point, the sparse-index does not handle these 'git checkout'
commands correctly. Or rather, it _does_ reject the 'git checkout' when
we have the staged change, but for the wrong reason. It also rejects the
'git checkout' commands when there is no staged change and we want to
replace a directory with a file. A fix for that unstaged case will
follow in the next change, but that will make the sparse-index agree
with the full checkout case in these documented incorrect behaviors.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:40 +02:00
|
|
|
1>sparse-index-out \
|
|
|
|
|
2>sparse-index-err &&
|
|
|
|
|
|
|
|
|
|
# The full checkout deviates from the df-conflict-1 case here!
|
|
|
|
|
# It drops the change to folder1/larger-content and leaves the
|
unpack-trees: resolve sparse-directory/file conflicts
When running unpack_trees() with a sparse index, we attempt to operate
on the index without expanding the sparse directory entries. Thus, we
operate by manipulating entire directories and passing them to the
unpack function. In the case of the 'git checkout' command, this is the
twoway_merge() function.
There are several cases in twoway_merge() that handle different
situations. One new one to add is the case of a directory/file conflict
where the directory is sparse. Before the sparse index, such a conflict
would appear as a list of file additions and deletions. Now,
twoway_merge() initializes 'current', 'oldtree', and 'newtree' from
src[0], src[1], and src[2], then sets 'oldtree' to NULL because it is
equal to the df_conflict_entry. The way to determine that we have a
directory/file conflict is to test that 'current' and 'newtree' disagree
on being sparse directory entries.
When we are in this case, we want to resolve the situation by calling
merged_entry(). This allows replacing the 'current' entry with the
'newtree' entry. This is important for cases where we want to run 'git
checkout' across the conflict and have the new HEAD represent the new
file type at that path. The first NEEDSWORK comment dropped in t1092
demonstrates this necessary behavior.
However, we still are in a confusing state when 'current' corresponds to
a staged change within a sparse directory that is not present at HEAD.
This should be atypical, because it requires adding a change outside of
the sparse-checkout cone, but it is possible. Since we are unable to
determine that this is a staged change within twoway_merge(), we cannot
add a case to reject the merge at this point. I believe this is due to
the use of df_conflict_entry in the place of 'oldtree' instead of using
the valud at HEAD, which would provide some perspective to this
decision. Any change that would allow this differentiation for staged
entries would need to involve information further up in unpack_trees().
That work should be done, sometime, because we are further confusing the
behavior of a directory/file conflict when staging a change in the
directory. The two cases 'checkout behaves oddly with df-conflict-?' in
t1092 demonstrate that even without a sparse-checkout, Git is not
consistent in its behavior. Neither of the two options seems correct,
either. This change makes the sparse-index behave differently than the
typcial sparse-checkout case, but it does match the full checkout
behavior in the df-conflict-2 case.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:41 +02:00
|
|
|
# folder1 path as-is on disk. The sparse-index behaves the same.
|
t1092: document bad 'git checkout' behavior
Add new branches to the test repo that demonstrate directory/file
conflicts in different ways. Since the directory 'folder1/' has
adjacent files 'folder1-', 'folder1.txt', and 'folder10' it causes
searches for 'folder1/' to land in a different place in the index than a
search for 'folder1'. This causes a change in behavior when working with
the df-conflict-1 and df-conflict-2 branches, whose only difference is
that the first uses 'folder1' as the conflict and the other uses
'folder2' which does not have these adjacent files.
We can extend two tests that compare the behavior across different 'git
checkout' commands, and we see already that the behavior will be
different in some cases and not in others. The difference between the
two test loops is that one uses 'git reset --hard' between iterations.
Further, we isolate the behavior of creating a staged change within a
directory and then checking out a branch where that directory is
replaced with a file. A full checkout behaves differently across these
two cases, while a sparse-checkout cone behaves consistently. In both
cases, the behavior is wrong. In one case, the staged change is dropped
entirely. The other case the staged change is kept, replacing the file
at that location, but none of the other files in the directory are kept.
Likely, the correct behavior in this case is to reject the checkout and
report the conflict, leaving HEAD in its previous location. None of the
cases behave this way currently. Use comments to demonstrate that the
tested behavior is only a documentation of the current, incorrect
behavior to ensure we do not _accidentally_ change it. Instead, we would
prefer to change it on purpose with a future change.
At this point, the sparse-index does not handle these 'git checkout'
commands correctly. Or rather, it _does_ reject the 'git checkout' when
we have the staged change, but for the wrong reason. It also rejects the
'git checkout' commands when there is no staged change and we want to
replace a directory with a file. A fix for that unstaged case will
follow in the next change, but that will make the sparse-index agree
with the full checkout case in these documented incorrect behaviors.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:40 +02:00
|
|
|
test_must_be_empty full-checkout-out &&
|
unpack-trees: resolve sparse-directory/file conflicts
When running unpack_trees() with a sparse index, we attempt to operate
on the index without expanding the sparse directory entries. Thus, we
operate by manipulating entire directories and passing them to the
unpack function. In the case of the 'git checkout' command, this is the
twoway_merge() function.
There are several cases in twoway_merge() that handle different
situations. One new one to add is the case of a directory/file conflict
where the directory is sparse. Before the sparse index, such a conflict
would appear as a list of file additions and deletions. Now,
twoway_merge() initializes 'current', 'oldtree', and 'newtree' from
src[0], src[1], and src[2], then sets 'oldtree' to NULL because it is
equal to the df_conflict_entry. The way to determine that we have a
directory/file conflict is to test that 'current' and 'newtree' disagree
on being sparse directory entries.
When we are in this case, we want to resolve the situation by calling
merged_entry(). This allows replacing the 'current' entry with the
'newtree' entry. This is important for cases where we want to run 'git
checkout' across the conflict and have the new HEAD represent the new
file type at that path. The first NEEDSWORK comment dropped in t1092
demonstrates this necessary behavior.
However, we still are in a confusing state when 'current' corresponds to
a staged change within a sparse directory that is not present at HEAD.
This should be atypical, because it requires adding a change outside of
the sparse-checkout cone, but it is possible. Since we are unable to
determine that this is a staged change within twoway_merge(), we cannot
add a case to reject the merge at this point. I believe this is due to
the use of df_conflict_entry in the place of 'oldtree' instead of using
the valud at HEAD, which would provide some perspective to this
decision. Any change that would allow this differentiation for staged
entries would need to involve information further up in unpack_trees().
That work should be done, sometime, because we are further confusing the
behavior of a directory/file conflict when staging a change in the
directory. The two cases 'checkout behaves oddly with df-conflict-?' in
t1092 demonstrate that even without a sparse-checkout, Git is not
consistent in its behavior. Neither of the two options seems correct,
either. This change makes the sparse-index behave differently than the
typcial sparse-checkout case, but it does match the full checkout
behavior in the df-conflict-2 case.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:41 +02:00
|
|
|
test_must_be_empty sparse-index-out &&
|
t1092: document bad 'git checkout' behavior
Add new branches to the test repo that demonstrate directory/file
conflicts in different ways. Since the directory 'folder1/' has
adjacent files 'folder1-', 'folder1.txt', and 'folder10' it causes
searches for 'folder1/' to land in a different place in the index than a
search for 'folder1'. This causes a change in behavior when working with
the df-conflict-1 and df-conflict-2 branches, whose only difference is
that the first uses 'folder1' as the conflict and the other uses
'folder2' which does not have these adjacent files.
We can extend two tests that compare the behavior across different 'git
checkout' commands, and we see already that the behavior will be
different in some cases and not in others. The difference between the
two test loops is that one uses 'git reset --hard' between iterations.
Further, we isolate the behavior of creating a staged change within a
directory and then checking out a branch where that directory is
replaced with a file. A full checkout behaves differently across these
two cases, while a sparse-checkout cone behaves consistently. In both
cases, the behavior is wrong. In one case, the staged change is dropped
entirely. The other case the staged change is kept, replacing the file
at that location, but none of the other files in the directory are kept.
Likely, the correct behavior in this case is to reject the checkout and
report the conflict, leaving HEAD in its previous location. None of the
cases behave this way currently. Use comments to demonstrate that the
tested behavior is only a documentation of the current, incorrect
behavior to ensure we do not _accidentally_ change it. Instead, we would
prefer to change it on purpose with a future change.
At this point, the sparse-index does not handle these 'git checkout'
commands correctly. Or rather, it _does_ reject the 'git checkout' when
we have the staged change, but for the wrong reason. It also rejects the
'git checkout' commands when there is no staged change and we want to
replace a directory with a file. A fix for that unstaged case will
follow in the next change, but that will make the sparse-index agree
with the full checkout case in these documented incorrect behaviors.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:40 +02:00
|
|
|
|
|
|
|
|
# In the sparse-checkout case, the checkout deletes the folder1
|
|
|
|
|
# file and adds the folder1/larger-content file, leaving all other
|
|
|
|
|
# paths that were in folder1/ as deleted (without any warning).
|
|
|
|
|
cat >expect <<-EOF &&
|
|
|
|
|
D folder2
|
|
|
|
|
A folder2/larger-content
|
|
|
|
|
EOF
|
|
|
|
|
test_cmp expect sparse-checkout-out &&
|
|
|
|
|
|
|
|
|
|
# Switched to branch df-conflict-1
|
unpack-trees: resolve sparse-directory/file conflicts
When running unpack_trees() with a sparse index, we attempt to operate
on the index without expanding the sparse directory entries. Thus, we
operate by manipulating entire directories and passing them to the
unpack function. In the case of the 'git checkout' command, this is the
twoway_merge() function.
There are several cases in twoway_merge() that handle different
situations. One new one to add is the case of a directory/file conflict
where the directory is sparse. Before the sparse index, such a conflict
would appear as a list of file additions and deletions. Now,
twoway_merge() initializes 'current', 'oldtree', and 'newtree' from
src[0], src[1], and src[2], then sets 'oldtree' to NULL because it is
equal to the df_conflict_entry. The way to determine that we have a
directory/file conflict is to test that 'current' and 'newtree' disagree
on being sparse directory entries.
When we are in this case, we want to resolve the situation by calling
merged_entry(). This allows replacing the 'current' entry with the
'newtree' entry. This is important for cases where we want to run 'git
checkout' across the conflict and have the new HEAD represent the new
file type at that path. The first NEEDSWORK comment dropped in t1092
demonstrates this necessary behavior.
However, we still are in a confusing state when 'current' corresponds to
a staged change within a sparse directory that is not present at HEAD.
This should be atypical, because it requires adding a change outside of
the sparse-checkout cone, but it is possible. Since we are unable to
determine that this is a staged change within twoway_merge(), we cannot
add a case to reject the merge at this point. I believe this is due to
the use of df_conflict_entry in the place of 'oldtree' instead of using
the valud at HEAD, which would provide some perspective to this
decision. Any change that would allow this differentiation for staged
entries would need to involve information further up in unpack_trees().
That work should be done, sometime, because we are further confusing the
behavior of a directory/file conflict when staging a change in the
directory. The two cases 'checkout behaves oddly with df-conflict-?' in
t1092 demonstrate that even without a sparse-checkout, Git is not
consistent in its behavior. Neither of the two options seems correct,
either. This change makes the sparse-index behave differently than the
typcial sparse-checkout case, but it does match the full checkout
behavior in the df-conflict-2 case.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:41 +02:00
|
|
|
test_cmp full-checkout-err sparse-checkout-err &&
|
|
|
|
|
test_cmp full-checkout-err sparse-index-err
|
t1092: document bad 'git checkout' behavior
Add new branches to the test repo that demonstrate directory/file
conflicts in different ways. Since the directory 'folder1/' has
adjacent files 'folder1-', 'folder1.txt', and 'folder10' it causes
searches for 'folder1/' to land in a different place in the index than a
search for 'folder1'. This causes a change in behavior when working with
the df-conflict-1 and df-conflict-2 branches, whose only difference is
that the first uses 'folder1' as the conflict and the other uses
'folder2' which does not have these adjacent files.
We can extend two tests that compare the behavior across different 'git
checkout' commands, and we see already that the behavior will be
different in some cases and not in others. The difference between the
two test loops is that one uses 'git reset --hard' between iterations.
Further, we isolate the behavior of creating a staged change within a
directory and then checking out a branch where that directory is
replaced with a file. A full checkout behaves differently across these
two cases, while a sparse-checkout cone behaves consistently. In both
cases, the behavior is wrong. In one case, the staged change is dropped
entirely. The other case the staged change is kept, replacing the file
at that location, but none of the other files in the directory are kept.
Likely, the correct behavior in this case is to reject the checkout and
report the conflict, leaving HEAD in its previous location. None of the
cases behave this way currently. Use comments to demonstrate that the
tested behavior is only a documentation of the current, incorrect
behavior to ensure we do not _accidentally_ change it. Instead, we would
prefer to change it on purpose with a future change.
At this point, the sparse-index does not handle these 'git checkout'
commands correctly. Or rather, it _does_ reject the 'git checkout' when
we have the staged change, but for the wrong reason. It also rejects the
'git checkout' commands when there is no staged change and we want to
replace a directory with a file. A fix for that unstaged case will
follow in the next change, but that will make the sparse-index agree
with the full checkout case in these documented incorrect behaviors.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20 22:14:40 +02:00
|
|
|
'
|
|
|
|
|
|
2021-01-23 20:58:19 +01:00
|
|
|
test_done
|