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

> > The nice thing is that the two strategies can co-exist. So if it does
> > turn out to have any regressions, it's an easy revert to switch back,
> > and even post-release users can switch at runtime. We have pull.twohead,
> > but I don't think we have an equivalent that would impact a bare "git
> > merge" or "git rebase -m". Maybe it would be worth adding those as an
> > escape hatch?
> 
> Actually, pull.twohead is not pull specific; it already affects merge,
> rebase (-m is the default for rebase, btw), cherry-pick, and revert.
> pull.twohead has affected a bare "git merge" since 1c7b76be7d ("Build
> in merge", 2008-07-07).  I thought it was weird that "merge strategy"
> for the merge command was specified via a config option under "pull",
> and included my misgivings about it in the commit message of
> 14c4586c2d ("merge,rebase,revert: select ort or recursive by config or
> environment", 2020-11-02) when I made sequencer.c pay attention to
> that config option as well:
> 
> """
>     Also, allow folks to pick the new algorithm via config setting.  It
>     turns out builtin/merge.c already had a way to allow users to specify a
>     different default merge algorithm: pull.twohead.  Rather odd
>     configuration name (especially to be in the 'pull' namespace rather than
>     'merge') but it's there.  Add that same configuration to rebase,
>     cherry-pick, and revert.
> """
>
> But no one had an alternate suggestion or opinion on attempting to
> migrate the configuration to a different name, so it has just stuck.
> Anyway, if folks want to try out 'ort' with the 2.32 or 2.33 releases,
> they can set pull.twohead=ort.  Once we switch the default, they can
> set pull.twohead=recursive to get the old default.