On Wed, Aug 18, 2021 at 11:42 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > > 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".
