Re: [PATCH v2 00/20] fundamentals of merge-ort implementation

From: Derrick Stolee <stolee@gmail.com>
Date: Nov 7, 2020, 15:02 UTC
Message-ID: <ca61acbf-1757-5ddc-49f7-6da0cba4a647@gmail.com>
In-Reply-To: <CABPp-BGvgdK8vEu5+mHjy9=GPg-aVtforC4-AAYgs3RWkBwQJA@mail.gmail.com>

On 11/7/20 1:06 AM, Elijah Newren wrote:

Show 24 quoted lines

> Hi Derrick,
> 
> On Tue, Nov 3, 2020 at 8:36 AM Elijah Newren <newren@gmail.com> 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@gmail.com/),
>> 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