2021-01-24 03:58:19 +08: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 21:10:55 +08:00
|
|
|
GIT_TEST_SPLIT_INDEX=0
|
2021-03-30 21:11:00 +08: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 21:10:55 +08:00
|
|
|
|
2021-01-24 03:58:19 +08:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup' '
|
|
|
|
|
git init initial-repo &&
|
|
|
|
|
(
|
2021-03-30 21:10:49 +08:00
|
|
|
GIT_TEST_SPARSE_INDEX=0 &&
|
2021-01-24 03:58:19 +08: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 21:12:28 +08:00
|
|
|
mkdir deep/deeper1 deep/deeper2 deep/before deep/later &&
|
2021-01-24 03:58:19 +08:00
|
|
|
mkdir deep/deeper1/deepest &&
|
|
|
|
|
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 21:12:28 +08:00
|
|
|
cp a deep/before &&
|
2021-01-24 03:58:19 +08:00
|
|
|
cp a deep/deeper1 &&
|
|
|
|
|
cp a deep/deeper2 &&
|
2021-07-14 21:12:28 +08:00
|
|
|
cp a deep/later &&
|
2021-01-24 03:58:19 +08:00
|
|
|
cp a deep/deeper1/deepest &&
|
|
|
|
|
cp -r deep/deeper1/deepest deep/deeper2 &&
|
2021-07-14 21:12:28 +08: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-24 03:58:19 +08:00
|
|
|
git add . &&
|
|
|
|
|
git commit -m "initial commit" &&
|
|
|
|
|
git checkout -b base &&
|
|
|
|
|
for dir in folder1 folder2 deep
|
|
|
|
|
do
|
|
|
|
|
git checkout -b update-$dir &&
|
|
|
|
|
echo "updated $dir" >$dir/a &&
|
|
|
|
|
git commit -a -m "update $dir" || return 1
|
|
|
|
|
done &&
|
|
|
|
|
|
|
|
|
|
git checkout -b rename-base base &&
|
2021-07-14 21:12:27 +08:00
|
|
|
cat >folder1/larger-content <<-\EOF &&
|
2021-01-24 03:58:19 +08: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 21:12:28 +08:00
|
|
|
echo >>folder2/0/1 &&
|
|
|
|
|
echo stuff >>deep/deeper1/a &&
|
2021-01-24 03:58:19 +08: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 21:12:28 +08:00
|
|
|
echo more stuff >>deep/deeper1/a &&
|
|
|
|
|
rm folder2/0/1 &&
|
|
|
|
|
mkdir folder2/0/1 &&
|
|
|
|
|
echo >>folder2/0/1/1 &&
|
2021-01-24 03:58:19 +08: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 21:12:28 +08:00
|
|
|
echo >>folder2/0/1 &&
|
|
|
|
|
rm -rf folder1/0/0 &&
|
|
|
|
|
echo >>folder1/0/0 &&
|
2021-01-24 03:58:19 +08: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-21 04:14:40 +08: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-01-24 03:58:19 +08:00
|
|
|
git checkout -b deepest base &&
|
|
|
|
|
echo "updated deepest" >deep/deeper1/deepest/a &&
|
|
|
|
|
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 21:10:49 +08:00
|
|
|
|
|
|
|
|
cp -r initial-repo sparse-index &&
|
|
|
|
|
git -C sparse-index reset --hard &&
|
2021-01-24 03:58:19 +08:00
|
|
|
|
|
|
|
|
# initialize sparse-checkout definitions
|
2021-03-30 21:10:49 +08:00
|
|
|
git -C sparse-checkout sparse-checkout init --cone &&
|
|
|
|
|
git -C sparse-checkout sparse-checkout set deep &&
|
2021-03-30 21:11:00 +08: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-24 03:58:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
run_on_sparse () {
|
|
|
|
|
(
|
|
|
|
|
cd sparse-checkout &&
|
2021-05-26 04:52:34 +08:00
|
|
|
GIT_PROGRESS_DELAY=100000 "$@" >../sparse-checkout-out 2>../sparse-checkout-err
|
2021-03-30 21:10:49 +08:00
|
|
|
) &&
|
|
|
|
|
(
|
|
|
|
|
cd sparse-index &&
|
2021-05-26 04:52:34 +08:00
|
|
|
GIT_PROGRESS_DELAY=100000 "$@" >../sparse-index-out 2>../sparse-index-err
|
2021-01-24 03:58:19 +08:00
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
run_on_all () {
|
|
|
|
|
(
|
|
|
|
|
cd full-checkout &&
|
2021-05-26 04:52:34 +08:00
|
|
|
GIT_PROGRESS_DELAY=100000 "$@" >../full-checkout-out 2>../full-checkout-err
|
2021-01-24 03:58:19 +08:00
|
|
|
) &&
|
2021-03-30 21:10:46 +08:00
|
|
|
run_on_sparse "$@"
|
2021-01-24 03:58:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test_all_match () {
|
2021-03-30 21:10:46 +08:00
|
|
|
run_on_all "$@" &&
|
2021-01-24 03:58:19 +08: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 21:10:55 +08: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-24 03:58:19 +08:00
|
|
|
}
|
|
|
|
|
|
2021-03-30 21:10:49 +08:00
|
|
|
test_sparse_match () {
|
|
|
|
|
run_on_sparse "$@" &&
|
|
|
|
|
test_cmp sparse-checkout-out sparse-index-out &&
|
|
|
|
|
test_cmp sparse-checkout-err sparse-index-err
|
|
|
|
|
}
|
|
|
|
|
|
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 21:10:55 +08: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 21:11:00 +08: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 21:10:55 +08: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 21:11:00 +08: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 21:10:55 +08: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 21:11:00 +08: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 21:10:55 +08:00
|
|
|
'
|
|
|
|
|
|
2021-03-30 21:10:51 +08:00
|
|
|
test_expect_success 'expanded in-memory index matches full index' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
test_sparse_match test-tool read-cache --expand --table
|
|
|
|
|
'
|
|
|
|
|
|
2021-01-24 03:58:19 +08: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 21:10:55 +08:00
|
|
|
test_sparse_match ls &&
|
2021-01-24 03:58:19 +08: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 21:10:46 +08:00
|
|
|
run_on_all touch README.md &&
|
2021-01-24 03:58:19 +08: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 21:12:36 +08: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-24 03:58:19 +08:00
|
|
|
test_expect_success 'add, commit, checkout' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
write_script edit-contents <<-\EOF &&
|
|
|
|
|
echo text >>$1
|
|
|
|
|
EOF
|
2021-03-30 21:10:46 +08:00
|
|
|
run_on_all ../edit-contents README.md &&
|
2021-01-24 03:58:19 +08: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 21:10:46 +08:00
|
|
|
run_on_all ../edit-contents README.md &&
|
2021-01-24 03:58:19 +08: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 21:10:46 +08:00
|
|
|
run_on_all ../edit-contents deep/newfile &&
|
2021-01-24 03:58:19 +08: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 -
|
|
|
|
|
'
|
|
|
|
|
|
2021-06-29 10:13:04 +08: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-07-14 21:12:29 +08:00
|
|
|
test_expect_success 'status/add: outside sparse cone' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
# adding a "missing" file outside the cone should fail
|
|
|
|
|
test_sparse_match test_must_fail git add folder1/a &&
|
|
|
|
|
|
|
|
|
|
# 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 &&
|
|
|
|
|
|
|
|
|
|
# This "git add folder1/a" fails with a warning
|
|
|
|
|
# in the sparse repos, differing from the full
|
|
|
|
|
# repo. This is intentional.
|
|
|
|
|
test_sparse_match test_must_fail git add folder1/a &&
|
|
|
|
|
test_sparse_match test_must_fail git add --refresh folder1/a &&
|
|
|
|
|
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 folder1/new &&
|
|
|
|
|
|
|
|
|
|
run_on_all ../edit-contents folder1/newer &&
|
|
|
|
|
test_all_match git add folder1/ &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git commit -m folder1/newer
|
|
|
|
|
'
|
|
|
|
|
|
2021-01-24 03:58:19 +08: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
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'diff --staged' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
write_script edit-contents <<-\EOF &&
|
|
|
|
|
echo text >>README.md
|
|
|
|
|
EOF
|
2021-03-30 21:10:46 +08:00
|
|
|
run_on_all ../edit-contents &&
|
2021-01-24 03:58:19 +08:00
|
|
|
|
|
|
|
|
test_all_match git diff &&
|
|
|
|
|
test_all_match git diff --staged &&
|
|
|
|
|
test_all_match git add README.md &&
|
|
|
|
|
test_all_match git diff &&
|
|
|
|
|
test_all_match git diff --staged
|
|
|
|
|
'
|
|
|
|
|
|
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-21 04:14:40 +08:00
|
|
|
# NEEDSWORK: sparse-checkout behaves differently from full-checkout when
|
|
|
|
|
# running this test with 'df-conflict-2' after 'df-conflict-1'.
|
2021-07-14 21:12:28 +08:00
|
|
|
test_expect_success 'diff with renames and conflicts' '
|
2021-01-24 03:58:19 +08: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-21 04:14:40 +08:00
|
|
|
for branch in rename-out-to-out \
|
|
|
|
|
rename-out-to-in \
|
|
|
|
|
rename-in-to-out \
|
|
|
|
|
df-conflict-1 \
|
|
|
|
|
fd-conflict
|
2021-01-24 03:58:19 +08:00
|
|
|
do
|
|
|
|
|
test_all_match git checkout rename-base &&
|
2021-07-14 21:12:28 +08:00
|
|
|
test_all_match git checkout $branch -- . &&
|
|
|
|
|
test_all_match git status --porcelain=v2 &&
|
|
|
|
|
test_all_match git diff --staged --no-renames &&
|
|
|
|
|
test_all_match git diff --staged --find-renames || return 1
|
|
|
|
|
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-21 04:14:40 +08: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-21 04:14:41 +08: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-21 04:14:40 +08:00
|
|
|
fd-conflict
|
2021-07-14 21:12:28 +08: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-01-24 03:58:19 +08:00
|
|
|
test_all_match git diff --staged --no-renames &&
|
|
|
|
|
test_all_match git diff --staged --find-renames || return 1
|
|
|
|
|
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 &&
|
|
|
|
|
|
|
|
|
|
test_all_match git blame a &&
|
|
|
|
|
test_all_match git blame deep/a &&
|
|
|
|
|
test_all_match git blame deep/deeper1/a &&
|
|
|
|
|
test_all_match git blame deep/deeper1/deepest/a
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
# TODO: blame currently does not support blaming files outside of the
|
|
|
|
|
# sparse definition. It complains that the file doesn't exist locally.
|
|
|
|
|
test_expect_failure 'blame with pathspec outside sparse definition' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
test_all_match git blame folder1/a &&
|
|
|
|
|
test_all_match git blame folder2/a &&
|
|
|
|
|
test_all_match git blame deep/deeper2/a &&
|
|
|
|
|
test_all_match git blame deep/deeper2/deepest/a
|
|
|
|
|
'
|
|
|
|
|
|
2021-07-14 21:12:40 +08:00
|
|
|
# NEEDSWORK: a sparse-checkout behaves differently from a full checkout
|
|
|
|
|
# in this scenario, but it shouldn't.
|
2021-01-24 03:58:19 +08:00
|
|
|
test_expect_failure 'checkout and reset (mixed)' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout -b reset-test update-deep &&
|
|
|
|
|
test_all_match git reset deepest &&
|
|
|
|
|
test_all_match git reset update-folder1 &&
|
|
|
|
|
test_all_match git reset update-folder2
|
|
|
|
|
'
|
|
|
|
|
|
2021-07-14 21:12:40 +08:00
|
|
|
# NEEDSWORK: a sparse-checkout behaves differently from a full checkout
|
|
|
|
|
# in this scenario, but it shouldn't.
|
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 21:10:55 +08:00
|
|
|
test_expect_success 'checkout and reset (mixed) [sparse]' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
test_sparse_match git checkout -b reset-test update-deep &&
|
|
|
|
|
test_sparse_match git reset deepest &&
|
|
|
|
|
test_sparse_match git reset update-folder1 &&
|
|
|
|
|
test_sparse_match git reset update-folder2
|
|
|
|
|
'
|
|
|
|
|
|
2021-01-24 03:58:19 +08:00
|
|
|
test_expect_success 'merge' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
test_all_match git checkout -b merge update-deep &&
|
|
|
|
|
test_all_match git merge -m "folder1" update-folder1 &&
|
|
|
|
|
test_all_match git rev-parse HEAD^{tree} &&
|
|
|
|
|
test_all_match git merge -m "folder2" update-folder2 &&
|
|
|
|
|
test_all_match git rev-parse HEAD^{tree}
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
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 21:12:25 +08: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-24 03:58:19 +08:00
|
|
|
test_expect_success 'clean' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
echo bogus >>.gitignore &&
|
|
|
|
|
run_on_all cp ../.gitignore . &&
|
|
|
|
|
test_all_match git add .gitignore &&
|
2021-03-30 21:10:46 +08:00
|
|
|
test_all_match git commit -m "ignore bogus files" &&
|
2021-01-24 03:58:19 +08: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 21:10:55 +08:00
|
|
|
test_sparse_match ls &&
|
|
|
|
|
test_sparse_match ls folder1 &&
|
2021-01-24 03:58:19 +08: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 21:10:55 +08:00
|
|
|
test_sparse_match ls &&
|
|
|
|
|
test_sparse_match ls folder1 &&
|
2021-01-24 03:58:19 +08: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 21:10:55 +08:00
|
|
|
test_sparse_match ls &&
|
|
|
|
|
test_sparse_match ls folder1 &&
|
2021-01-24 03:58:19 +08: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 21:10:55 +08:00
|
|
|
test_sparse_match test_path_is_dir folder1
|
2021-01-24 03:58:19 +08:00
|
|
|
'
|
|
|
|
|
|
2021-03-30 21:10:56 +08:00
|
|
|
test_expect_success 'submodule handling' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
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-03-30 21:10:58 +08:00
|
|
|
test_expect_success 'sparse-index is expanded and converted back' '
|
|
|
|
|
init_repos &&
|
|
|
|
|
|
2021-03-30 21:11:00 +08:00
|
|
|
GIT_TRACE2_EVENT="$(pwd)/trace2.txt" GIT_TRACE2_EVENT_NESTING=10 \
|
|
|
|
|
git -C sparse-index -c core.fsmonitor="" reset --hard &&
|
|
|
|
|
test_region index convert_to_sparse trace2.txt &&
|
2021-07-14 21:12:37 +08:00
|
|
|
test_region index ensure_full_index trace2.txt
|
|
|
|
|
'
|
2021-03-30 21:11:00 +08:00
|
|
|
|
2021-06-29 10:13:04 +08:00
|
|
|
ensure_not_expanded () {
|
2021-07-14 21:12:37 +08:00
|
|
|
rm -f trace2.txt &&
|
|
|
|
|
echo >>sparse-index/untracked.txt &&
|
2021-03-30 21:11:00 +08:00
|
|
|
GIT_TRACE2_EVENT="$(pwd)/trace2.txt" GIT_TRACE2_EVENT_NESTING=10 \
|
2021-06-29 10:13:04 +08:00
|
|
|
git -C sparse-index "$@" &&
|
2021-07-14 21:12:37 +08:00
|
|
|
test_region ! index ensure_full_index trace2.txt
|
2021-06-29 10:13:04 +08: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 10:13:06 +08: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 - &&
|
|
|
|
|
git -C sparse-index reset --hard &&
|
|
|
|
|
ensure_not_expanded checkout rename-out-to-out -- deep/deeper1 &&
|
|
|
|
|
git -C sparse-index reset --hard &&
|
|
|
|
|
ensure_not_expanded restore -s rename-out-to-out -- deep/deeper1
|
2021-03-30 21:10:58 +08:00
|
|
|
'
|
|
|
|
|
|
2021-07-14 21:12:40 +08:00
|
|
|
# NEEDSWORK: a sparse-checkout behaves differently from a full checkout
|
|
|
|
|
# in this scenario, but it shouldn't.
|
2021-07-14 21:12:38 +08: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-21 04:14:40 +08: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-21 04:14:41 +08: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-21 04:14:40 +08: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-21 04:14:41 +08: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-21 04:14:40 +08: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-21 04:14:41 +08: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-21 04:14:40 +08: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-21 04:14:41 +08: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-21 04:14:40 +08: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-21 04:14:41 +08: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-21 04:14:40 +08: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-21 04:14:41 +08: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-21 04:14:40 +08: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-21 04:14:41 +08: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-21 04:14:40 +08:00
|
|
|
'
|
|
|
|
|
|
2021-01-24 03:58:19 +08:00
|
|
|
test_done
|
