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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 18, 2021, 22:22 UTC
Message-ID: <xmqqbl5u4cmj.fsf@gitster.g>
In-Reply-To: <b3c7e700-f36c-d58f-0c49-450444df8c63@gmail.com>

Derrick Stolee <stolee@gmail.com> writes:

Show 18 quoted lines

> On 8/18/2021 2:10 PM, Junio C Hamano wrote:
>> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
>> 
>>> From: Derrick Stolee <dstolee@microsoft.com>
>>>
>>> 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).

Ah, thanks for explanation. The tests being touched are not about correctness of the merge results but the damage the operation would make to the sparseness of the index, and because in the longer term the recursive backend is on its way out, we do want to focus on testing how ORT performs.

> 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.

No, that's OK.

It was unclear from the proposed log message (hence my questions), but if it is made clear that we have a good reason why we want to see how the sparse-index works with ORT, explicitly testing with ORT like your patch does is the right thing to do, I would think.

With GIT_TEST_MERGE_ALGORITHM set to ort and exported, it is puzzling why some "git merge" invocations gets "-s ort" in the same patch, though.

Thanks.