Elijah Newren <newren@xxxxxxxxx> writes: > 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 somehow thought that direct calls to merge_recursive() and merge_recursive_generic() are not affected with that environment variable, so you cannot influence what happens during "git am -3" and "git stash apply" with that, but perhaps I was not reading the code correctly. It seems that merge_recursive() and merge_ort_recursive() are interface compatible and the latter can serve as a drop-in replacement for the former?
