Re: [PATCH 1/6] t1092: use ORT merge strategy

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 20, 2021, 23:32 UTC
Message-ID: <xmqq7dgfu1zb.fsf@gitster.g>
In-Reply-To: <CABPp-BEtOWUGCcn3B0On80=tMZ_Re9ScHnBiwPPPFY=x2TwG5Q@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 17 quoted lines

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