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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> 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?