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.6 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 2F2181F66F for ; Sat, 7 Nov 2020 06:14:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727298AbgKGGG1 (ORCPT ); Sat, 7 Nov 2020 01:06:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727146AbgKGGG0 (ORCPT ); Sat, 7 Nov 2020 01:06:26 -0500 Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 991A8C0613CF for ; Fri, 6 Nov 2020 22:06:26 -0800 (PST) Received: by mail-oi1-x243.google.com with SMTP id m143so3900032oig.7 for ; Fri, 06 Nov 2020 22:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j19Ne7Ujpl07FHKcUKYNx00z+vwlP95uuR6id8s6vUI=; b=fqebL3TPRvZH9gjvodQ4L4z3bdg18UXragV/ununuNAhEoknlqZDesgsPe+0XlmbWJ 13Bj//9jhQoePYmYeYyXdFesf1R3v0qU6pqn6ntxgNHAliuzWksKBiH30RA+eJcz00o/ Y+WwVB6uxbjE7RvARt41tfHc763yeTna/IzpT5tCpG2nF1v9HbqQcqVzbIicGFodlXss B3od6xaXkm58/Vj4jJeA2vHtlkt1GYyj7dxBwIMQtamBz2kFhS+FqZEvR8EVW/4/FltZ OH2rXEE51OiFB8JYg5dzlzq5KhfVGu0YSwRgjm69EP4fNtmunSUn2+4pRS3g/WX+aM/u zhtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j19Ne7Ujpl07FHKcUKYNx00z+vwlP95uuR6id8s6vUI=; b=l8iTNLm1L+D1c0mhvxD6mXifJciE8yaKhbrnv0yRLvBHMgwtZOAk3D4nqZw2DxldL7 /z66CtkeMlpBLyBDoJco77Mk5C2n30e9y/GiAoKexAAtzlbi5xRBqBVjZea754b6+mZD gYW2Nhm35kdXuPmSufR0gjBIfoQywe6sW4xbZIB3wgmKrQ3uTjr0vX3jcmPXv6zyZiEI 6rKVYDf8x3lDxqkyu33EKElroGEVKUEdqXYplvdhW0x4p3Z8ffwQEPYAiFzUxE5X54vW bEdsMwhOlLOzrlTXM82ZNSAtIf/nsVshkKRD0AL9/4x9+V4k/37oYMpdfCUprSYGuSTx 2ngQ== X-Gm-Message-State: AOAM530bru4rVDpCgilACLlhxC3CHKwI6MTjmHC9sg6aHTYq88ylXRsD WePmeKgJeFAQXXsqXEJbgCYbAlnqEkQwazEBSRQ= X-Google-Smtp-Source: ABdhPJxHInTDt1tJXQbN1trpuQ2H1CoyPAKfBzmuBoUkX44zAyL5GMW+k1d3blin5cH/X92RMpvihZuTTpbhz8CpzPc= X-Received: by 2002:aca:b4d7:: with SMTP id d206mr3448021oif.39.1604729185859; Fri, 06 Nov 2020 22:06:25 -0800 (PST) MIME-Version: 1.0 References: <20201102204344.342633-1-newren@gmail.com> <0197d698-e966-f0bb-4d77-0183e93d9bef@gmail.com> In-Reply-To: From: Elijah Newren Date: Fri, 6 Nov 2020 22:06:14 -0800 Message-ID: Subject: Re: [PATCH v2 00/20] fundamentals of merge-ort implementation To: Derrick Stolee Cc: Git Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Hi Derrick, On Tue, Nov 3, 2020 at 8:36 AM Elijah Newren wrote: > > On Tue, Nov 3, 2020 at 6:50 AM Derrick Stolee wrote: > > > > On 11/2/2020 3:43 PM, Elijah Newren wrote: > > > This series depends on a merge of en/strmap (after updating to v3) and > > > en/merge-ort-api-null-impl. > > > > > > As promised, here's the update of the series due to the strmap > > > updates...and two other tiny updates. > > > > Hi Elijah, > > > > I'm sorry that I've been unavailable to read and review your series > > on this topic. I'm very excited about the opportunities here, and I > > wanted to take your topic and merge it with our microsoft/git fork > > so I could test the performance in a Scalar-enabled monorepo. My > > branch is available in my fork [1] > > > > [1] https://github.com/derrickstolee/git/tree/merge-ort-vfs > > > > However, I'm unable to discover how to trigger your ort strategy, > > even for a simple rebase. Perhaps you could supply a recommended > > command for testing? > > > > Thanks, > > -Stolee > > If you want to test performance, you shouldn't test this particular > submission, you should test the end result which exists as the 'ort' > branch of my repo. It actually passes all the tests rather than just > trivial cherry-picks and rebases, and has lots (and lots) of > performance work that hasn't even begun at the point of the > 'ort-basics' branch. (However, it also contains some unrelated memory > cleanup in revision.c, chdir-notify.c, and a number of other places > because I was annoyed that a rebase wouldn't run valgrind-free and > made it harder to spot my memory leaks. And the day I went hunting > those memory "leaks", I went and grabbed some unrelated memory leaks > too. If it causes you merge conflicts, let me know and I'll try to > create a branch for you that hash the minimal changes outside of > merge-ort*.[ch] and diffcore*.[ch]) > > All that said, for testing either branch you just need to first set > pull.twohead=ort in your git config (see > https://lore.kernel.org/git/61217a83bd7ff0ce9016eb4df9ded4fdf29a506c.1604360734.git.gitgitgadget@gmail.com/), > or, if running regression tests, set GIT_TEST_MERGE_ALGORITHM=ort. I probably also should have mentioned that merge-ort does not (yet?) heed merge.renames configuration setting; it always detects renames. I know you run with merge.renames=false, so you won't quite get an apples-to-apples comparison. However, part of my point was I wanted to make renames fast enough that they could be left turned on, even for the large scale repos, so I'm very interested in your experience. If you need an escape hatch, though, just put a "return 1" at the top of detect_and_process_renames() to turn it off. Oh, and I went through and re-merged all the merge commits in the linux kernel and found a bug in merge-ort while doing that (causing it to die, not to merge badly). I'm kind of surprised that none of my testcases triggered that failure earlier; if you're testing it out, you might want to update to get the fix (commit 067e5c1a38, "merge-ort: fix bug with cached_target_names not being initialized in redos", 2020-11-06).