Re: Trimming 'deadheads' (TREESAME 2nd parent) from revision walks?

[Philip Oakley <philipoakley@iee.email>]

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