On 3/17/2021 5:27 PM, Elijah Newren via GitGitGadget wrote:

This series depends on ort-perf-batch-10[1], and obsoletes the ort-remainder
topic[2] (that hadn't been picked up yet, so hopefully this doesn't cause
any confusion)

With this series, merge-ort is ready for general usage -- it passes all
tests, passes dozens of tests that don't under merge-recursive, and
merge-ort is is already significantly faster than merge-recursive when
rename detection is involved. Users can select merge-ort 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.

Changes since v1:

 * subsumed the ort-remainder topic (the first 10 patches), which has
   already been reviewed by both Ævar and Stolee[2].
 * the next two patches were the original v1, reviewed by Stolee
 * the final patch is new and adds testing.

Sorry for the delay in looking at this. I read the two series before
this, and found this to be a good union of them.

My only question on the final patch is a two parter:

1. Did you mean to go this far?
2. Did you want to go farther?

Mostly: how much do we want to prepare for ORT as the default
strategy, at the expense of reducing testing of the recursive
strategy?

Thanks,
-Stolee