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?

On Tue, Aug 03, 2021 at 03:08:53PM -0700, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

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.

Yeah, I am happy even starting the 'next' portion sooner than the
release. :) As Elijah explained, we already have that emergency measure
in place (pull.merge).

-Peff

On Tue, Aug 3, 2021 at 4:37 PM Jeff King [off-list ref] wrote:

On Tue, Aug 03, 2021 at 03:08:53PM -0700, Junio C Hamano wrote:

quoted

Jeff King [off-list ref] writes:

quoted

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.

Yeah, I am happy even starting the 'next' portion sooner than the
release. :) As Elijah explained, we already have that emergency measure
in place (pull.merge).

s/pull.merge/pull.twohead/  Relevant commits:

1c7b76be7d ("Build in merge", 2008-07-07)

14c4586c2d ("merge,rebase,revert: select ort or recursive by config or
environment", 2020-11-02)

On Tue, Aug 3, 2021 at 4:08 PM Junio C Hamano [off-list ref] wrote:

Jeff King [off-list ref] writes:

quoted

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.

So I think I made a small mess here.  Much of the second patch wasn't
specific to the change of default, so I decided to split it up into a
bunch of tiny documentation fixes that could be beneficial before 2.33
(https://lore.kernel.org/git/pull.1059.git.git.1628004920.gitgitgadget@gmail.com/)

So, perhaps I should submit a v2 of this series which is based on that
other one; then the second patch will only have the pieces specific to
the change of default left.

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.

I think what you're asking for here is the `pull.twohead` config
option that has existed for a while (despite its name, it affects
merge, rebase, cherry-pick, and revert).