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

Jeff King [off-list ref] writes:

It would make sense to me to do the switch in 'next' early in the
post-v2.33 cycle. It can cook there for a bit, but I think we have found
that it's much more likely to see actual use once it hits 'master'. So I
don't see a particular reason to have it sit in 'next' for a long time.
We should get as much exposure in 'master' during the v2.34 cycle as
possible.

I do not mind queuing what is available today to 'next' to gain 2
more weeks of dogfood time during the pre-release freeze.  If an
simple escape hatch that lets us say "anytime we ask ort, use
recursive instead as an emergency measure" can be added with a
trivially obvious small patch, that would be a plus.

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?