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

From: Jeff King <peff@peff.net>
Date: Sep 20, 2021, 20:50 UTC
Message-ID: <YUj0J+jY0jURkipM@coredump.intra.peff.net>
In-Reply-To: <88dfc31a-187c-6609-0df6-d6b970b1a136@iee.email>

On Mon, Sep 20, 2021 at 12:40:21PM +0100, Philip Oakley wrote:

Show 6 quoted lines

> 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