On Tue, Aug 24, 2021 at 2:52 PM Derrick Stolee via GitGitGadget <gitgitgadget@xxxxxxxxx> wrote: > > This series integrates the sparse index with commands that perform merges > such as 'git merge', 'git cherry-pick', 'git revert' (free with > cherry-pick), and 'git rebase'. > > When the ORT merge strategy is enabled, this allows most merges to succeed > without expanding the sparse index, leading to significant performance > gains. I tested these changes against an internal monorepo with over 2 > million paths at HEAD but with a sparse-checkout that only has ~60,000 files > within the sparse-checkout cone. 'git merge' commands went from 5-6 seconds > to 0.750-1.250s. > > In the case of the recursive merge strategy, the sparse index is expanded > before the recursive algorithm proceeds. We expect that this is as good as > we can get with that strategy. When the strategy shifts to ORT as the > default, then this will not be a problem except for users who decide to > change the behavior. > > Most of the hard work was done by previous series, such as > ds/sparse-index-ignored-files (which this series is based on). > > > 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. > > * 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. 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.
