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

On Tue, Aug 03, 2021 at 10:57:12AM -0600, Elijah Newren wrote:

quoted

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.

Ah, thanks for clarifying. I think we are in good shape, then. We could
possibly introduce merge.twohead as a synonym, but given that most
people would probably not ever even look at this, it may not be worth
worrying about.

-Peff