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=-4.2 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, 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 A8C731F8C8 for ; Tue, 21 Sep 2021 13:36:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233092AbhIUNhe (ORCPT ); Tue, 21 Sep 2021 09:37:34 -0400 Received: from smtp.hosts.co.uk ([85.233.160.19]:40689 "EHLO smtp.hosts.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233038AbhIUNhe (ORCPT ); Tue, 21 Sep 2021 09:37:34 -0400 Received: from host-84-13-154-214.opaltelecom.net ([84.13.154.214] helo=[192.168.1.37]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1mSfwK-0003R8-4Z; Tue, 21 Sep 2021 14:36:04 +0100 Subject: Re: Trimming 'deadheads' (TREESAME 2nd parent) from revision walks? To: Jeff King Cc: =?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?= , Git List References: <01fe28d8-2887-bc42-c91b-c3237b5186a7@iee.email> <87k0jcb01k.fsf@evledraar.gmail.com> <88dfc31a-187c-6609-0df6-d6b970b1a136@iee.email> From: Philip Oakley Message-ID: <9b85811f-de5d-24b3-36f6-7e2f9be6cae0@iee.email> Date: Tue, 21 Sep 2021 14:36:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Hi Peff, On 20/09/2021 21:50, Jeff King wrote: > On Mon, Sep 20, 2021 at 12:40:21PM +0100, Philip Oakley wrote: > >> One thing that catches me, and I think others, is how the 'strategies' >> work. IIUC a merge will look at each line in the diff, and accept any >> change on either side that has no conflicts within the context zone. >> It's only when there are changes from both sides that the selection >> strategy kicks in. But it is difficult to describe, so it's easy to be >> confused. > I think you might be confusing the "ours" strategy (which takes the > tree state of the first parent entirely) with the "ours" (and "theirs") > options of the merge-recursive (or ort) strategy. > > You can see the difference with: > > git init repo > cd repo > > echo base >file > git add file > git commit -m base > > echo main >file > git add file > git commit -m main > > git checkout -b side HEAD^ > echo side >file > echo unrelated >another > git add file another > git commit -m side > > git checkout -b strategy-ours main > git merge -s ours side > > git checkout -b option-ours main > git merge -X ours side > > The strategy-ours merge will drop "another", because it was not in the > first parent. Whereas option-ours will keep it, preferring the > first parent only for the conflict in "file". > > You could construct a similar example where instead of a second file, > there's enough content in "file" that some of it does not conflict. > > -Peff Thanks for the clarification. I was probably over thinking the problem, by starting at the default and adding conditions that are extras to that, rather than  reducing the conditions! The `theirs` strategy is really only suitable for maintainers, rather than solo coders, as it need to be 'old releases` that are kept, rather 'old cruft` (I've generated too much of that in my time). Dscho's scripts (for anyone interested) for GfW are in https://github.com/git-for-windows/build-extra/blob/main/shears.sh#L16-L18 and  https://github.com/git-for-windows/build-extra/blob/main/ever-green.sh, though from the script perspective it's an 'ours' strategy. Dscho has to locate the start commit via it's subject line, rather than it's topology. -- Philip