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 42C861F852 for ; Thu, 13 Jan 2022 08:06:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232565AbiAMICC (ORCPT ); Thu, 13 Jan 2022 03:02:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231391AbiAMICB (ORCPT ); Thu, 13 Jan 2022 03:02:01 -0500 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4A0EDC06173F for ; Thu, 13 Jan 2022 00:02:01 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id k15so19853025edk.13 for ; Thu, 13 Jan 2022 00:02:01 -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; bh=xwHwF51a1lFjPDxxViuRVeHiaiup/QF+EMjjpMAljoA=; b=OTyKFjRLv5HOFGP02ZbYoVRrs4rMOUvhBIgOkdmS2CwVw1lcTPxa+z9qlAQPAviNgd tqo5iqA0wm4cUZsJU//2CcqKEOdlTxXrvlBGL3TRKjAi0+orGBHX8OcBa4BC/w6Wr2E4 Gvh44le7GTYgIWoP65Fk6t01LpuHZBtuL6Q+wlKAGoedOtpP0JcPMnVugwCrlBUwDrJv oHrwOMwCOTQ9xCT9aLAPDwvBx59vllHrPEphl2siAF21U2PY5qi+4ux5vqizqv/AJm5t OO0skqVkmwkio9ZgM5f0Ij3BehEPQXsgiRM9hyfuM7FF5HJtqIh6vXhtUh5n77sdaQ8I J/OA== 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; bh=xwHwF51a1lFjPDxxViuRVeHiaiup/QF+EMjjpMAljoA=; b=yLMo6TZ4i33fvFBQU9Nbty6khw/P+wZh/TBA7AWkSKAf7YeJ36zLskYJ/Nq584Et3g 3PlyrXDA07SEK0OY1P9oPlKowS1ZswRxm3Gn5t9SSqY3VWVyG15p6PusFd3RLWqlkhpg xkzP6T5OITRSRxeXynUwvr5nOZKgYIaCTLdfyWCTiIlfmBp6CGZQQRjmiO34s2DdE5vo nTOUEfKJqZBvicFnES+5tG/3ezl0NJp2gZmKUTKtBShLWKYCrygspWQinbx2J2/ATPOU U1oYf7/nxYQ3fCInt/QVCHzAMkeEqPmvlGHb9G+IdlhvNFnXCyFFvrTJXx0YMCLeVY6S aegA== X-Gm-Message-State: AOAM532Br/gGPz++6vB29R7xV4iJz1IBxz1JCD2f+11gtIUH7dkxkqhB 6BV6AKntmPIy7oW/9HqeyJdkbdga0yIQtv5T2Gs= X-Google-Smtp-Source: ABdhPJyAuPzmzrZDeikcSMWxvaVBgXw1IJ90+3PbJZSrsQo4MjfGfbv7UH0sHDNkmpfgYgIEJ9T6Nw9u/AjE1P69nXs= X-Received: by 2002:a50:f086:: with SMTP id v6mr3176378edl.94.1642060919863; Thu, 13 Jan 2022 00:01:59 -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: Thu, 13 Jan 2022 00:01:47 -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" Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Wed, Jan 12, 2022 at 10:08 PM Junio C Hamano wrote: > > Elijah Newren writes: > > >> 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? > > Didn't we "deprecate" but still indefinitely support "annotate"? I > have been assuming that recursive will be in that category after ort > establishes itself. But in that case, we suggested folks use "blame" instead of "annotate", right? >From a user point of view, my intention was that "ort" is just the newer version of "recursive" (which happens to be an essentially total rewrite). ort only got a separate name because we wanted a special testing period and a way for users to select the old version of recursive or the new version of recursive. Of course, that period is multiple release cycles, so both names will persist, but they'll just be aliases. Once we switch "recursive" to mean "ort" so they both run the exact same code, I was intending to have the documentation prefer the term "recursive" over "ort" since it is a more meaningful user-facing name.