This tiny series depends on ort-perf-batch-10[1]. If the ort-remainder topic[2] is merged with this series, then the result is a version of merge-ort ready for general usage. Users can select it by (a) passing -sort to either git merge or git rebase, or (b) by setting pull.twohead=ort [3], or (c) by setting GIT_TEST_MERGE_ALGORITHM=ort. There are still more optimizations that will be submitted for merge-ort, but folks don't need to wait for all of them to start using it. The version of merge-ort that comes from merging both these topics will run the testsuite cleanly under GIT_MERGE_TEST_ALGORITHM=ort, which includes passing every test that merge-recursive does and passing dozens of tests that merge-recursive doesn't. merge-ort is also already significantly faster than merge-recursive when rename detection is involved. I'll send out a separate email later requesting feedback about what people would like to see before switching the default from merge-recursive to merge-ort. [1] https://lore.kernel.org/git/pull.853.git.1615674128.gitgitgadget@xxxxxxxxx/ [2] https://lore.kernel.org/git/pull.973.v2.git.git.1615271086.gitgitgadget@xxxxxxxxx/ [3] See commit 14c4586c2d ("merge,rebase,revert: select ort or recursive by config or environment", 2020-11-02) Elijah Newren (2): Revert "merge-ort: ignore the directory rename split conflict for now" t6423: mark remaining expected failure under merge-ort as such merge-ort.c | 13 +------------ t/t6423-merge-rename-directories.sh | 2 +- 2 files changed, 2 insertions(+), 13 deletions(-) base-commit: ac0ba91ce275227f5df8f16fb986308ff88b198b Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-905%2Fgitgitgadget%2Fort-readiness-v1 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-905/gitgitgadget/ort-readiness-v1 Pull-Request: https://github.com/gitgitgadget/git/pull/905 -- gitgitgadget
