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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 3, 2021, 22:08 UTC
Message-ID: <xmqqim0mtc3u.fsf@gitster.g>
In-Reply-To: <YQlnNXgk3qcGb5Bk@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 6 quoted lines

> 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.

Show 6 quoted lines

> 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?