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
