Re: mergetool: what to do about deleting precious files?

"Philip Oakley" [off-list ref] writes:

From: "Junio C Hamano" <redacted>

Thanks for the replies. Let's see if I've got it...

quoted

"Philip Oakley" [off-list ref] writes:

quoted

If I now understand correctly, the merge process flow is:

* canonicalise content (eol, smudge-clean, $id, renormalise, etc)
* diff the content (internal, or GIT_EXTERNAL_DIFF)
* apply the diff
* if conflicts, only then use merge-driver/tool

Would that be a correct interpretation?

Not quite.  There are a lot more going on before any of those steps:

* Find the common ancestor commit (which could be many).

IIUC Git selects one of them, rather than all if there are many (which
then may not be the optimum)

Not quite.  The interface to "git merge-$backend" can take more than
one and "git merge" frontend does pass them to the backend.  How
they are used depends on the backend.  The "resolve" one tries to
use all of them at once; the "recursive" one tries merge across them
to come up with a tree to be used as a single "virtual common
ancestor".  But details does not matter for the purpose of analysing
the case that triggered this discussion.

quoted

* Walk the three trees (the common ancestor's, ours and theirs) in
  parallel, noticing what happened to each path.  Depending on what
  happened to the path in each branch, the merge may or may not
  "conflict" (e.g. when both sides added exactly the same contents
  to the same path, they are not counted as conflicting.  when we
  removed while they modified, they show as conflicting).

I'm assuming here that this is the sha-oid comparison, and then
checking the tree/blob names that match them. (the top tree not having
a name). So here "conflict free" is that the sha-oids match.

Also, I thnk this is saying that added or removed trees or blobs are
in some sense are 'conflict free' (though still subject to rename/move
detection etc). An added file/blob would be conflict free for merging
into it's tree, yes?

After "recursive" figures out the renames, an addition that still
remains (i.e. not matched up with a deletion elsewhere) would be a
candidate to be added silently (except that D/F conflict can still
be diagnosed).

quoted

* For paths that are conflicting, feed the canonicalized content of
  the versions from common, ours and theirs to the file-level merge
  driver.

So this is where any .gitattibutes settings come in, or is the merge
driver after the diff step? (which could also be a user diff?)

I think you answered this yourself in your "Ok, I think I can see
how I was confused..." paragraph.