On 11/7/20 1:06 AM, Elijah Newren wrote: > Hi Derrick, > > On Tue, Nov 3, 2020 at 8:36 AM Elijah Newren <newren@xxxxxxxxx> wrote: >> All that said, for testing either branch you just need to first set >> pull.twohead=ort in your git config (see >> https://lore.kernel.org/git/61217a83bd7ff0ce9016eb4df9ded4fdf29a506c.1604360734.git.gitgitgadget@xxxxxxxxx/), >> or, if running regression tests, set GIT_TEST_MERGE_ALGORITHM=ort. > > I probably also should have mentioned that merge-ort does not (yet?) > heed merge.renames configuration setting; it always detects renames. > I know you run with merge.renames=false, so you won't quite get an > apples-to-apples comparison. However, part of my point was I wanted > to make renames fast enough that they could be left turned on, even > for the large scale repos, so I'm very interested in your experience. > If you need an escape hatch, though, just put a "return 1" at the top > of detect_and_process_renames() to turn it off. > > Oh, and I went through and re-merged all the merge commits in the > linux kernel and found a bug in merge-ort while doing that (causing it > to die, not to merge badly). I'm kind of surprised that none of my > testcases triggered that failure earlier; if you're testing it out, > you might want to update to get the fix (commit 067e5c1a38, > "merge-ort: fix bug with cached_target_names not being initialized in > redos", 2020-11-06). I did manage to do some testing to see what happens with a large repo under a small sparse-checkout. And using trace2, I was able to see that your code is being exercised. Unfortunately, I didn't see any performance improvement, and that is likely due to needing to expand the index entirely when checking out the merge commit. Is there a command to construct a merge commit without actually checking it out? That would reduce the time spent expanding the index, which would allow your algorithm to really show its benefits! Thanks, -Stolee
