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=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, 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 ECD561FA19 for ; Wed, 12 Jan 2022 20:13:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243310AbiALUG4 (ORCPT ); Wed, 12 Jan 2022 15:06:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357519AbiALUGv (ORCPT ); Wed, 12 Jan 2022 15:06:51 -0500 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0AE9EC061751 for ; Wed, 12 Jan 2022 12:06:51 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id a18so14435764edj.7 for ; Wed, 12 Jan 2022 12:06:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YRbRa88uAyxenbjAcXDo7/3Ex94muwkA9ss4Wl5EAzk=; b=LTBqIz7nGMfctKhU1XhAE7KRvXt25P47486WOLq2gVh+/aLRM5PN4pFf5cb03PU2lf aXK96os3j7voJJk9f6rvdUULENCh9MOuDtV8/954LTfVGWJxVSq3uOON2Icv4XQe64+k 1L84/mbw7d20QzcvyrUV4wd3KtBIJHz4ARZ45uRAIP8Jjmqs6sbGTiLEcCyrOgi0cZKY DXLN3SrOtfgf/Agy9Q7Ni2KdGpQCTAPpVA+E1alIrOeirJtNkY1pcNm4Jq32q1F7Hx2M 3SIAXHOLeL8yx6pmAphFqGrY+pDGZMA/5FMJ+JdFNtz8M0Fzl9rvgXF/kQJd55KTw1v9 25FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YRbRa88uAyxenbjAcXDo7/3Ex94muwkA9ss4Wl5EAzk=; b=K+RrbUUVRf+LI72jS0i+aoswHxMJlFL5/NEn0a/NI6GzqIl1Qaa2MuC+4SC4tU6Ry0 exsc7lWchZiSrpVwl6adOAnT01sFatyC1bRX0yvsIjuj8MHIxqMjmf8mxmF3f2GRD5/4 qGCEThNJvZ0aXZLCPiyBNBMnPXI/+rSnmv6wDHW4SVhLLNCuLgL30FNUnfX/kSKk+vGJ sbVBbTp7IVc2NXrnV++f6MHDbuSnI89MdQWzFGzXcN8W+4SNmkrwALZuJoclV5gWvBe3 fkEtDXuZurb4oX92d8/QLs5ytZpHGDWuK0Qvy4QzdR0k2J89mPIpip2NXE3ycloH1XK8 AZ0A== X-Gm-Message-State: AOAM532iYI+bluWOpecWbrCs/Yvz/kyBRlsHPaonOhlb/pmwyruT7+mo 03GAp2Ii4vbYsxAmPbtIuXgf7QFlzEYq+RsaJio= X-Google-Smtp-Source: ABdhPJw42RbEI+ITqA15wgCoDM8k8yZUCuciMFNxvKBpFNS37xCa9i8RKSS6/a2JWH8N1ChWrJEv+Z7ahzkZUEiarjc= X-Received: by 2002:a17:907:2da3:: with SMTP id gt35mr1034021ejc.493.1642018009520; Wed, 12 Jan 2022 12:06:49 -0800 (PST) MIME-Version: 1.0 References: <20220105163324.73369-1-chriscool@tuxfamily.org> <220111.86mtk2xb1y.gmgdl@evledraar.gmail.com> In-Reply-To: From: Elijah Newren Date: Wed, 12 Jan 2022 12:06:38 -0800 Message-ID: Subject: Re: [RFC PATCH 0/2] Introduce new merge-tree-ort command To: Junio C Hamano Cc: =?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?= , Johannes Schindelin , Christian Couder , Git Mailing List , Christian Couder , Taylor Blau Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Wed, Jan 12, 2022 at 10:06 AM Junio C Hamano wrote: > > Elijah Newren writes: > ... > I however suspect that =C3=86var didn't mean by "legacy merge plumbing > built-in" the strategy backends. IOW, I had an impression that what > is on the chopping block is merge-tree and not merge-recursive. > > But since you brought up deprecation of recursive, let's spend a few > minutes on the topic. Not sure it matters, but for reference, =C3=86var explicitly brought up merge-recursive.c. The fuller quote was: > >> I.e. is it really costing us > >> to just leave these "legacy merge" plumbing built-ins and > >> merge-recursive.c etc. in place? Because he brought it up, I decided to address it. It was unclear to me whether he meant builtin/merge-recursive.c or the toplevel merge-recursive.c, so I just addressed both. > I suspect that we may be able to just invoke ort when recursive is > invoked, and such a wrapping may even be easier than wrapping "git > blame" to replace "git annotate" (where a command line option or two > needs to change behaviour). Yes, that was the plan I had. > I doubt there is -X > that affects recursive that ORT does not understand, Technically there are currently two. As documented in merge-strategies.txt, ORT takes the same -X options as recursive, but currently ignores both -Xdiff-algorithm (instead passing HISTOGRAM_DIFF down to ll_merge()), and -Xno-renames (instead passing DIFF_DETECT_RENAME down to diffcore_rename_extended()). I guess there are three if you count -Xpatience separately from -Xdiff-algorithm=3Dpatience. > so it may be quite simple to deprecate "merge -s recursive". Yes...but why deprecate? I thought the plan was to (eventually) make requests for either `recursive` or `ort` be handled by running the `ort` backend. Making that kind of switch is much smaller than the one we already made to switch the default backend from `recursive` to `ort`, so I'm not sure I see what we gain by doing such a switch in stages. Maybe I'm missing something?