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-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,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 093221F86C for ; Sun, 29 Nov 2020 07:46:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726661AbgK2HoY (ORCPT ); Sun, 29 Nov 2020 02:44:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725830AbgK2HoJ (ORCPT ); Sun, 29 Nov 2020 02:44:09 -0500 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 252CAC0613D4 for ; Sat, 28 Nov 2020 23:43:29 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id 23so10824823wrc.8 for ; Sat, 28 Nov 2020 23:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:in-reply-to:references:from:date:subject:fcc :content-transfer-encoding:mime-version:to:cc; bh=4d6geiWr0GOYAu9feXFM09HfSTtPef86PNI0FJUU0gk=; b=WHnwOmxmQ6A6tX8Ailg3LYDpPQR3hfpfNWnZ48j+56Wngtj7yZzd9rqCHGrEtHiHA+ ++R8Vf3YyC9WbpUu2lfJ9M6VWHw9XvSqxrDJitDNvjsLqoXlt+npLCYlvR8d2P1z8gig aJdlteLmfrb4NkrYeiPAyNW/ZsKIlbIDSmw9nbA4eCuI5vok88MQAl9VvOyyXZvvneYX AEziC8NICYX8M+7A7p6aCqyKmqSwnN1YkuSQqZNuxwgigtndlML8cdjGNVgP4MO3pOp+ bS2ToPHWivZTL3zj56HQd1TG/HhOzmYXz8ZOLaLUg5LF4Bc80MJHjlClgp9fDhpWBTuU 7nVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:in-reply-to:references:from:date :subject:fcc:content-transfer-encoding:mime-version:to:cc; bh=4d6geiWr0GOYAu9feXFM09HfSTtPef86PNI0FJUU0gk=; b=ILCvo2w4oUHdQHkalscYOiTq1iJkw9DzD+9TwhnsNqI/fIEcYPiHGiQfUxMVO9iR40 NSkvmA4zpVWOOeOTgrIHCaeE8AoB58o2hgug167gLRYnxIkFFTPZ+ubMcvOtuy3a9bZw rN/sGzoY9AV3EWB+sgY0SmUQKLkIjD/hJ8BAZQ9tR0JQH26m0nKrE6oI714v8p+QWaVC 7o/GcQWUqnakM2XGZiPy5LyfykC4jVi2QCMEsCO6uSkAWiW0DAhgA+Qk9outUNsoyR02 wk3vxK3+Wf6wpqonLm6LkY++SIrHBoYekNbvFhL+uQs3XoBmvYqMgcztkLhy07PBzAp0 cYTA== X-Gm-Message-State: AOAM532PBWgY0wKxA+MDqZaTvxiFNEIXbGrq/pbJ+jqU/BlaunnrbxG2 a1hev47WyZdFviEU3zXjNht76QcI19k= X-Google-Smtp-Source: ABdhPJx1hy6oBR+veGhT45JuKvaHI9C4hbTxM0x2da2FHPceyaklRYu2oG2wC1UtjEe2zY6d3ELF3g== X-Received: by 2002:adf:eb05:: with SMTP id s5mr7975883wrn.333.1606635807619; Sat, 28 Nov 2020 23:43:27 -0800 (PST) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id b73sm36656152wmb.0.2020.11.28.23.43.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Nov 2020 23:43:27 -0800 (PST) Message-Id: <5615f0eecb49a7605d316b71fc1c89229c0277f4.1606635803.git.gitgitgadget@gmail.com> In-Reply-To: References: From: "Elijah Newren via GitGitGadget" Date: Sun, 29 Nov 2020 07:43:06 +0000 Subject: [PATCH 03/20] merge-ort: port merge_start() from merge-recursive Fcc: Sent Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 To: git@vger.kernel.org Cc: Elijah Newren , Elijah Newren Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: Elijah Newren merge_start() basically does a bunch of sanity checks, then allocates and initializes opt->priv -- a struct merge_options_internal. Most of the sanity checks are usable as-is. The allocation/intialization is a bit different since merge-ort has a very different merge_options_internal than merge-recursive, but the idea is the same. The weirdest part here is that merge-ort and merge-recursive use the same struct merge_options, even though merge_options has a number of fields that are oddly specific to merge-recursive's internal implementation and don't even make sense with merge-ort's high-level design (e.g. buffer_output, which merge-ort has to always do). I reused the same data structure because: * most the fields made sense to both merge algorithms * making a new struct would have required making new enums or somehow externalizing them, and that was getting messy. * it simplifies converting the existing callers by not having to have different code paths for merge_options setup. I also marked detect_renames as ignored. We can revisit that later, but in short: merge-recursive allowed turning off rename detection because it was sometimes glacially slow. When you speed something up by a few orders of magnitude, it's worth revisiting whether that justification is still relevant. Besides, if folks find it's still too slow, perhaps they have a better scaling case than I could find and maybe it turns up some more optimizations we can add. If it still is needed as an option, it is easy to add later. Signed-off-by: Elijah Newren --- merge-ort.c | 45 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 44 insertions(+), 1 deletion(-) diff --git a/merge-ort.c b/merge-ort.c index 97ef2276bd..3581a7d278 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -17,6 +17,8 @@ #include "cache.h" #include "merge-ort.h" +#include "diff.h" +#include "diffcore.h" #include "strmap.h" #include "tree.h" @@ -204,7 +206,48 @@ void merge_finalize(struct merge_options *opt, static void merge_start(struct merge_options *opt, struct merge_result *result) { - die("Not yet implemented."); + /* Sanity checks on opt */ + assert(opt->repo); + + assert(opt->branch1 && opt->branch2); + + assert(opt->detect_directory_renames >= MERGE_DIRECTORY_RENAMES_NONE && + opt->detect_directory_renames <= MERGE_DIRECTORY_RENAMES_TRUE); + assert(opt->rename_limit >= -1); + assert(opt->rename_score >= 0 && opt->rename_score <= MAX_SCORE); + assert(opt->show_rename_progress >= 0 && opt->show_rename_progress <= 1); + + assert(opt->xdl_opts >= 0); + assert(opt->recursive_variant >= MERGE_VARIANT_NORMAL && + opt->recursive_variant <= MERGE_VARIANT_THEIRS); + + /* + * detect_renames, verbosity, buffer_output, and obuf are ignored + * fields that were used by "recursive" rather than "ort" -- but + * sanity check them anyway. + */ + assert(opt->detect_renames >= -1 && + opt->detect_renames <= DIFF_DETECT_COPY); + assert(opt->verbosity >= 0 && opt->verbosity <= 5); + assert(opt->buffer_output <= 2); + assert(opt->obuf.len == 0); + + assert(opt->priv == NULL); + + /* Initialization of opt->priv, our internal merge data */ + opt->priv = xcalloc(1, sizeof(*opt->priv)); + + /* + * Although we initialize opt->priv->paths with strdup_strings=0, + * that's just to avoid making yet another copy of an allocated + * string. Putting the entry into paths means we are taking + * ownership, so we will later free it. + * + * In contrast, conflicted just has a subset of keys from paths, so + * we don't want to free those (it'd be a duplicate free). + */ + strmap_init_with_options(&opt->priv->paths, NULL, 0); + strmap_init_with_options(&opt->priv->conflicted, NULL, 0); } /* -- gitgitgadget