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.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MALFORMED_FREEMAIL, RCVD_IN_DNSWL_MED,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 B54F21F8C6 for ; Fri, 10 Sep 2021 12:08:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233000AbhIJMKG (ORCPT ); Fri, 10 Sep 2021 08:10:06 -0400 Received: from mout.gmx.net ([212.227.17.22]:43233 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232873AbhIJMKF (ORCPT ); Fri, 10 Sep 2021 08:10:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1631275726; bh=59aMM1SbqDo3dE8FMpXw2c3o8Ql4JroYPLcrxeDT8J4=; h=X-UI-Sender-Class:Date:From:To:cc:Subject:In-Reply-To:References; b=iTrDL76FUFx2Z7vH4gyYzZqn5IOe8kIdY6XJ8o9+7rwnGgCCMFGYqZVd6KghGLbZJ T0hscKUNdocGtaG/DXoXVqjTX0SWXDUXsItFPpDTLrJVOeg+PdwbNfPyMd9c8BHae/ jM1O38y2ZsMbA+z1U5xzQN+fmi1/U+gNo0R66Zco= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [172.30.86.174] ([213.196.213.44]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mk0NU-1mn1ja2XXs-00kPWt; Fri, 10 Sep 2021 14:08:46 +0200 Date: Fri, 10 Sep 2021 14:08:44 +0200 (CEST) From: Johannes Schindelin X-X-Sender: virtualbox@gitforwindows.org To: Elijah Newren cc: Johannes Sixt , Junio C Hamano , Johannes Schindelin via GitGitGadget , Git Mailing List , Eric Wong Subject: Re: [PATCH v2 0/7] Drop support for git rebase --preserve-merges In-Reply-To: Message-ID: References: <4e998676-4975-8ac2-35a0-34416938b62e@kdbg.org> User-Agent: Alpine 2.21.1 (DEB 209 2017-03-23) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Provags-ID: V03:K1:A6+8nervFHmyhF9dqESj+IIydxxqWWMEmG82TCcxeQb0l0giFi4 7ZGZldW09doukVpeO3yLzXDzXuAoyzwEt4buTXoAG9jE3fBiVX0MMzcRpA1qFXoWY//VLAU TYB8pEDdgemIQGtrx6PM5y1ECHknDo6H4JNQ/kvtrDxrRPt6f3oV5+smgyABhrmO5sSZP5K d3Z5ELsZDtcPbQrNWWw7A== X-UI-Out-Filterresults: notjunk:1;V03:K0:+Ywtp5pU52c=:WRNgLxhVUlYBgLMluriGOZ kNVX+GmjBTrgsNbHQZ1xRd/aJYKuRV1nkd7c25b6OREwiqQ446DOKj5xtYTzaJiP2nInPFFDi khGTA/XFpqyq8skjVP+uoSQ7eeZ1D6kxfgGB1ic7m2bXK398TP0ZAc5e9bwJ+bPaJgt7C3w2c 4DZ3T32WsmDsRz+rIqvd9DRGme7kZa0+BF5RsPoMcJ3RGIF5UqEoNoX9pOeUvyR5hpQhed4v2 s0oKkNfpQG3JBb95ZwfcoWtF7TX7k2wXeIDS3caTNIZjyKXRSUWeqMFqmb0GI/uuTSvhD1WP9 xYPZ/L/2/4P1QLkBD4gsLtI3bcRfsK9+GKU6s3k8QMnYpvAeJPUweszFkevLlZ7mOhVF532dN 50zYj77a4Css06IseXbrKqDXhtuID2B0HH5blqxJmiybi6Q2WwA7kvf1lW33ErOejm/r8YyJO mI8V/F9HpntabKIQ/s3A7dNo+BUMCp/9Hbiw8wAMWTC4o5xSmWwpfZKbpDofZGlSJy+lE2kvG EO7ycEzwSKsdT/hugMFeAMiFkXF4fBiWyAgNb1cweovZVGrd0DKu0PVEbPYfv2p3QVppOlCXq anC96UtxjOKES3RG6NjXo5FnPI5zQwqJ2rGJIgbQJ37bD19uvIc7E9jrKI5oqXHmo7NPcY68N Ja7qqIRH39t1i71PYmU4lCONCt/jlbRlc32Dfd2SYosykyXEYPx3k6Js/5VtqXDrmjdniX9B6 rVnLygCzn+m21LGpyIpJbHjxhh4G3WGVXYyNmRjZLCS6Ur17ipEZ5nvt7tyjbqyfQ4TaZf0aU bU7SWpyFBpjuEQdpnZ2XtSI3gQemIpv+qtScuytUliSaRSX23+KC9xWQkaj8lKhGV2b2WBXNU C7jUvgBRTzg+KJFyhQxsmoMicA2E3+v9z+YV3OxXPSAHG0xzoffoP+oUISNOdqzAX4R2X1ufh Y7EseWj/on68yZbTNGpuBun7S4VkfWQdJVwgpBA4jh/tXW0ioCyxUDfs45ssyFd1zIsqcNxFA RULWu2ISVWKTQiJA3BIxxv74qnF0pzpLrv6d7OmORMhKzLv4Q0qlR9Xr1vJ2uQfs4cJptHRCH g9p8aJ7roQOuZ0= Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Hi Elijah, On Tue, 7 Sep 2021, Elijah Newren wrote: > On Tue, Sep 7, 2021 at 11:51 AM Johannes Schindelin > wrote: > > > > On Thu, 2 Sep 2021, Johannes Sixt wrote: > > > > > Am 02.09.21 um 16:18 schrieb Johannes Schindelin: > > > > On Wed, 1 Sep 2021, Junio C Hamano wrote: > > > >> A good goal. There is no remaining use case where (a fictitious = and > > > >> properly working version of) "--preserve-merges" option cannot be > > > >> replaced by "--rebase-merges", is it? I somehow had a feeling th= at > > > >> the other Johannes (sorry if it weren't you, j6t) had cases that = the > > > >> former worked better, but perhaps I am mis-remembering things. > > > > > > > > I think that I managed to address whatever concerns there were abo= ut the > > > > `--rebase-merges` backend in the meantime. > > > > > > That was either my suggestion/desire to make no-rebase-cousins the > > > default. That has been settled. > > > > > > Or my wish not to redo the merge, but to replay the first-parent > > > difference. The idea never got traction, and I've long since abandon= ed > > > my implementation of it. > > > > Thank you for clarifying. > > > > Yes, I remember how that idea came up, and I even tried that strategy = for > > a couple of merging rebases of Git for Windows' branch thicket. Sadly,= it > > did not work half as well as I had hoped. > > > > The best idea I had back then still is in want of being implemented: s= ort > > of a "four-way merge". It is basically the same as a three-way merge, = but > > allows for the pre-images to differ in the context (and yes, this cann= ot > > be represented using the current conflict markers). Definitely not > > trivial. > > merge-ort opens a new possibility (since it does merges without > touching the index or working tree): Take the merge commit, M, that > you are trying to transplant. Hold on to it for a minute. Do what > rebase-merges does now; namely, do a simple merge of the desired new > branches that otherwise ignores M to get your new merge commit N. > Hang on to N too for a minute. Now use merge-ort to auto-remerge M > (much like AUTO_MERGE or --remerge-diff does) to get a new merge > commit that we'll call pre-M. If M was a clean merge that the user > didn't amend, then pre-M will match M. If M wasn't a clean merge or > was amended, then pre-M will otherwise differ from M by not including > any manual changes the user made when they originally created M -- > such as removing conflict markers, fixing semantic conflicts, evil > changes, etc. > > Now we've got three merge commits: pre-M, M, and N. (Technically, > pre-M and N might be toplevel trees rather than full commits, but > whatever.) The difference between pre-M and M represent the manual > work the user did in order to create M. Now, do a three-way > (non-recursive) merge of those commits, to get the rebased result, R. > This operation has the affect of applying the changes from pre-M to M > on top of N. > > There's obviously some edge cases (e.g. nested conflict markers), but > I think they're better than the edge cases presented by the > alternatives: > * the first-parent difference idea silently discards intermediate > changes from reapplying other patches (especially if other patches are > added or dropped), which to me feels _very_ dangerous > * the current rebase-merges idea silently discards manual user > changes within the original merge commit (i.e. it hopes that there is > no difference between pre-M and M), which can also be lossy > * I don't think this idea drops any data, but it does run the risk > of conflicts that are difficult to understand. But I suspect less so > than your five-way merge would entail. > > If the difficulty of conflicts in this scheme is too high, we could do > a few things like providing multiple versions (e.g. if either > pre-M:file or N:file had conflicts, or maybe if R:file has nested > conflicts, then place both R:file and N:file in the working tree > somewhere) or pointing at special commands that help users figure out > what went on (e.g. 'git log -1 --remerge-diff M -- file'). While I agree that `merge-ort` makes a lot of things much better, I think in this context we need to keep in mind that those nested merge conflicts can really hurt. In my tests (I tried to implement a strategy where a 3-way merge is done with M and N^, using the parent commits of M as merge parents successively, see https://lore.kernel.org/git/nycvar.QRO.7.76.6.1804130002090.65@ZVAVAG-6OXH= 6DA.rhebcr.pbec.zvpebfbsg.pbz/ for the nitty gritty), I ran into _nasty_ nested merge conflicts, even with trivial examples. And I came to the conviction that treating the merge conflict markers as Just Another Line was the main culprit. I wish I had the time to try out your proposed strategy with the conconcted example I presented in that mail I linked above. Because now I am curious what it would do... Ciao, Dscho