Re: [PATCH v2 0/6] Sparse Index: Integrate with merge, cherry-pick, rebase, and revert

From: Derrick Stolee <stolee@gmail.com>
Date: Aug 30, 2021, 17:26 UTC
Message-ID: <cac6803c-b66b-e3b5-b31f-e20695c8b5e6@gmail.com>
In-Reply-To: <CABPp-BFXk++dktLnaTTuCe+keqkNuPzGyVi4uFsOpE4VxqAUdw@mail.gmail.com>

On 8/27/2021 6:56 PM, Elijah Newren wrote:

> On Tue, Aug 24, 2021 at 2:52 PM Derrick Stolee via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
>>

...

Show 7 quoted lines

>> Updates in V2
>> =============
>>
>>  * The tests no longer specify GIT_TEST_MERGE_ALGORITHM or directly
>>    reference "-s ort". By relaxing this condition, I found an issue with
>>    'git cherry-pick' and 'git rebase' when using the 'recursive' algorithm
>>    which is fixed in a new patch.

This describes why the tests no longer use GIT_TEST_MERGE_ALGORITHM at the top. It improves coverage in case users opt-out of ORT. Instead,

>>  * Use the pul.twohead config to specify the ORT merge algorithm to avoid
>>    expanding the sparse index when that is what we are testing.
> 
> pull.twohead, not pul.twohead.

We use this config option to specify when we _really care_ about the ORT strategy as it is necessary to avoid expanding the full index.

Show 10 quoted lines

> I'm curious, though, why use it instead of just setting
> GIT_TEST_MERGE_ALGORITHM=ort?  That'd seem to avoid the need for the
> explicit subshells and the sane_unset calls.
> 
>>
>>  * Corrected some misstatements in my commit messages.
> 
> I read over v2.  Other than some minor questions about whether using
> GIT_TEST_MERGE_ALGORITHM=ort would be easier, and a typo still present
> from v1, the series looks good to me.

Sorry about the typo, as I fixed it in Patch 3 but not Patch 2. I will fix these in v3 after I send a v5 of the ignored files series.

Thanks, -Stolee