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

> 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