"Derrick Stolee via GitGitGadget" [off-list ref] writes:
From: Derrick Stolee <redacted>
The sparse index will be compatible with the ORT merge strategy, so
let's use it explicitly in our tests.
Unless you mean that the sparse index will only be compatible with
ort, but will never be with recursive, I do not quite see why this
is taking us into a good direction. Is this because we want to gain
test coverage for ort early, before we flip the default to ort [*1*]?
[Footnote]
*1* If the answer is "no, it is because sparse index will not work
with recursive", the please disregard the rest, but just in
case it is not...
It seems to me that it would let us live in the future in a more
comprehensive way if we tweaked merge_recursive() and/or
merge_recursive_generic() so that all internal callers, not just
builtin/merge.c, would redirect to the ort machinery when say
GIT_TEST_REPLACE_RECURSIVE_WITH_ORT environment exists, and
doing it that way we do not need to sprinkle "-srecursive" and
"-sort" everywhere in our tests at randomly chosen places to
give test coverage to both strategies.
quoted hunk
Signed-off-by: Derrick Stolee <redacted>
---
t/t1092-sparse-checkout-compatibility.sh | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/t/t1092-sparse-checkout-compatibility.sh b/t/t1092-sparse-checkout-compatibility.sh
index ddc86bb4152..3e01e70fa0b 100755
--- a/t/t1092-sparse-checkout-compatibility.sh
+++ b/t/t1092-sparse-checkout-compatibility.sh
@@ -7,6 +7,11 @@ GIT_TEST_SPARSE_INDEX=
. ./test-lib.sh
+# Force the use of the ORT merge algorithm until testing with the
+# recursive strategy. We expect ORT to be used with sparse-index.
+GIT_TEST_MERGE_ALGORITHM=ort
+export GIT_TEST_MERGE_ALGORITHM
+
test_expect_success 'setup' '
git init initial-repo &&
(
@@ -501,7 +506,7 @@ test_expect_success 'merge with conflict outside cone' '
test_all_match git checkout -b merge-tip merge-left &&
test_all_match git status --porcelain=v2 &&
- test_all_match test_must_fail git merge -m merge merge-right &&
+ test_all_match test_must_fail git merge -sort -m merge merge-right &&
test_all_match git status --porcelain=v2 &&
# Resolve the conflict in different ways:
@@ -531,7 +536,7 @@ test_expect_success 'merge with outside renames' '
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 merge -sort -m "$type" rename-$type &&
test_all_match git rev-parse HEAD^{tree} || return 1
done
'
On 8/18/2021 2:10 PM, Junio C Hamano wrote:
"Derrick Stolee via GitGitGadget" [off-list ref] writes:
quoted
From: Derrick Stolee <redacted>
The sparse index will be compatible with the ORT merge strategy, so
let's use it explicitly in our tests.
Unless you mean that the sparse index will only be compatible with
ort, but will never be with recursive, I do not quite see why this
is taking us into a good direction. Is this because we want to gain
test coverage for ort early, before we flip the default to ort [*1*]?
The sparse index will _work_ with the recursive merge strategy, it will
just continue to be slow, and likely slower than if we had a full index.
This is because the recursive merge algorithm will expand a sparse index
into a full one before doing any of its logic (hence my confidence that
it will work).
The main point why ORT is the focus is that the ORT strategy is required
so the sparse index can get the intended performance gains (i.e. it does
not expand in most cases). The ORT algorithm can resolve conflicts
outside the sparse-checkout cone without needing the index as a data
structure and instead the resulting tree is recorded in the correct
sparse directory entry.
[Footnote]
*1* If the answer is "no, it is because sparse index will not work
with recursive", the please disregard the rest, but just in
case it is not...
It seems to me that it would let us live in the future in a more
comprehensive way if we tweaked merge_recursive() and/or
merge_recursive_generic() so that all internal callers, not just
builtin/merge.c, would redirect to the ort machinery when say
GIT_TEST_REPLACE_RECURSIVE_WITH_ORT environment exists, and
doing it that way we do not need to sprinkle "-srecursive" and
"-sort" everywhere in our tests at randomly chosen places to
give test coverage to both strategies.
I could also change this patch to stop using ORT _all the time_ and
instead let the GIT_TEST_MERGE_ALGORITHM decide which is tested.
That is, except for the final tests that check that the index is not
expanded. Those tests must specify the ORT strategy explicitly.
I think I started playing with the GIT_TEST_MERGE_ALGORITHM because
it appears to override the command-line option, but I will need to
double-check that.
Thanks,
-Stolee
On Wed, Aug 18, 2021 at 11:42 AM Derrick Stolee [off-list ref] wrote:
quoted
It seems to me that it would let us live in the future in a more
comprehensive way if we tweaked merge_recursive() and/or
merge_recursive_generic() so that all internal callers, not just
builtin/merge.c, would redirect to the ort machinery when say
GIT_TEST_REPLACE_RECURSIVE_WITH_ORT environment exists, and
doing it that way we do not need to sprinkle "-srecursive" and
"-sort" everywhere in our tests at randomly chosen places to
give test coverage to both strategies.
GIT_TEST_MERGE_ALGORITHM already does this; the testsuite already had
`-s recursive` sprinkled everywhere (due to contrast with `-s
resolve`), but since I wanted to use all existing recursive tests as
ort tests, then rather than tweaking all the test files and copying
tests and whatnot, we decided to just have GIT_TEST_MERGE_ALGORITHM
reinterpret "recursive" to whatever GIT_TEST_MERGE_ALGORITHM says.
I could also change this patch to stop using ORT _all the time_ and
instead let the GIT_TEST_MERGE_ALGORITHM decide which is tested.
That is, except for the final tests that check that the index is not
expanded. Those tests must specify the ORT strategy explicitly.
I think I started playing with the GIT_TEST_MERGE_ALGORITHM because
it appears to override the command-line option, but I will need to
double-check that.
Yes, GIT_TEST_MERGE_ALGORITHM=ort reinterprets "recursive" to mean "ort".