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

[Jeff King <peff@peff.net>]

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