From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id C32531F8C6 for ; Tue, 3 Aug 2021 15:56:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237154AbhHCP4v (ORCPT ); Tue, 3 Aug 2021 11:56:51 -0400 Received: from cloud.peff.net ([104.130.231.41]:37050 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237063AbhHCP4u (ORCPT ); Tue, 3 Aug 2021 11:56:50 -0400 Received: (qmail 1291 invoked by uid 109); 3 Aug 2021 15:56:38 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Tue, 03 Aug 2021 15:56:38 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 14773 invoked by uid 111); 3 Aug 2021 15:56:38 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Tue, 03 Aug 2021 11:56:38 -0400 Authentication-Results: peff.net; auth=none Date: Tue, 3 Aug 2021 11:56:37 -0400 From: Jeff King To: Elijah Newren via GitGitGadget Cc: git@vger.kernel.org, Christian Couder , Derrick Stolee , Emily Shaffer , Eric Sunshine , Johannes Schindelin , Jonathan Nieder , Jonathan Tan , Junio C Hamano , Phillip Wood , =?utf-8?B?UmVuw6k=?= Scharfe , Taylor Blau , =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , Elijah Newren Subject: Re: [PATCH 0/2] [RFC] Switch default merge backend from recursive to ort Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Sun, Aug 01, 2021 at 12:07:39AM +0000, Elijah Newren via GitGitGadget wrote: > This is an RFC series designed to spur feedback about switching the default > merge backend (reviewing the patches is of secondary importance at this > point). Some questions: > > * Are there things others want before this series is considered for > inclusion? > * What kind of timeline do others think is reasonable? > * Would it be beneficial to let this series sit in 'next' for an extended > duration to gain more feedback? It looks like others gave some more specific review on the patches, but on the meta-topic of "do we switch, and when", my response is: yes, and soon. :) Having watched the development of merge-ort, plus all of the weird corner cases in merge-recursive we've seen over the years (many of which you found and added tests for while working on merge-ort!), my gut feeling is that the switch is _much_ more likely to fix problems people might see in the wild rather than cause them. 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. 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? -Peff