On Tue, Aug 03, 2021 at 10:57:12AM -0600, Elijah Newren wrote:
> > 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
