Re: [PATCH 0/2] [RFC] Switch default merge backend from recursive to ort

From: Derrick Stolee <stolee@gmail.com>
Date: Aug 2, 2021, 15:05 UTC
Message-ID: <ec1bb449-347a-924d-7462-3cef6facc0e9@gmail.com>
In-Reply-To: <pull.1055.git.git.1627776461.gitgitgadget@gmail.com>

On 7/31/2021 8:07 PM, Elijah Newren via GitGitGadget wrote:

Show 24 quoted lines

> This is an RFC series designed to spur feedback about switching the default
> merge backend (reviewing the patches is of secondary importance at this
> point). Some questions:
> 
>  * Are there things others want before this series is considered for
>    inclusion?
>  * What kind of timeline do others think is reasonable?
>  * Would it be beneficial to let this series sit in 'next' for an extended
>    duration to gain more feedback?
> 
> Some potentially useful context in relation to the above:
> 
>  * I've personally used the ort backend for well over a year
>  * I have ~50 testers using ort as the default merge backend since Nov.
>    2020.
>  * ort fixes known bugs in recursive, and there are no known regressions
>    (more testers may change that)
>  * ort is significantly faster than recursive
>  * ort provides one new feature already, and enables more that are on the
>    way
>  * The commit message of patch 1 has more details about the last three items
>    above
> 
> So...thoughts?

I fully endorse this change as soon as possible. I've applied the patches you supplied here and submitted a PR to microsoft/git [1] to take them.

[1] https://github.com/microsoft/git/pull/404

I've done my own share of testing on some of our private monorepos to see how ORT compares to the recursive algorithm. My data is not perhaps as rigorous as yours, but I did notice that the ORT algorithm was consistently within the 5-6 second range while the recursive algorithm would vary within the 7-20 second range (and some outliers near 30s).

Of course, I'm particularly excited about the benefits to the sparse index work. I also have a prototype of a 'git merge' integration with sparse index which was not very hard because the ORT strategy does not use the index as a data structure. With that change, my tests dropped to between 0.5s and 1.5 seconds. (This shows just how much my earlier timings were stuck on index reads and writes.) Now, the largest indicator of time is how long it takes to resolve text conflicts.

Thanks! What a monumental effort.

-Stolee