"Philip Oakley" [off-list ref] writes:
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).
* 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).
* For paths that are conflicting, feed the canonicalized content of
the versions from common, ours and theirs to the file-level merge
driver. The builtin file-level merge driver takes two xdiff (one
between ancestor and ours, the other between ancestore and
theirs) and reconciles them to produce the result. But that is
irrelevant in the context of "custom merge driver"; the builtin
one is skipped altogether and the custom contents merge driver
the user specified via the attributes is used instead.
Notice that the second step above has no customization knobs. Any
path the second step deems not to conflict is "merged cleanly"
without even triggering the "oops, ours and theirs did conflicting
changes, to the content; let's see how the final content should look
like" (aka the third step). This is *not* because "Git knows the
best"; it is merely that nobody felt the need for a mechanism to
allow customizing the second step.
And that is why I said you need a new customization mechanism if you
want to affect the outcome of the scenario that started this thread.
From: "Junio C Hamano" <redacted>
Thanks for the replies. Let's see if I've got it...
"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)
* 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?
IIUC, the comparison is therefore using the in-repo sha-oids;
unless --renormalise was given which will do a smudge-clean washing cycle
and recomute fresh canonical sha-oids for the comparison (rather than doing
it later).
* 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?)
The builtin file-level merge driver takes two xdiff (one
between ancestor and ours, the other between ancestore and
theirs) and reconciles them to produce the result. But that is
irrelevant in the context of "custom merge driver"; the builtin
one is skipped altogether and the custom contents merge driver
the user specified via the attributes is used instead.
Notice that the second step above has no customization knobs. Any
path the second step deems not to conflict is "merged cleanly"
without even triggering the "oops, ours and theirs did conflicting
changes, to the content; let's see how the final content should look
like" (aka the third step). This is *not* because "Git knows the
best"; it is merely that nobody felt the need for a mechanism to
allow customizing the second step.
And that is why I said you need a new customization mechanism if you
want to affect the outcome of the scenario that started this thread.
Ok, I think I can see how I was confused between the "tree merge" (oid
conflict detection) and the more usual (to users) "file merge" (line by
line, etc.). I wasn't sure where to find that as someone relatively new to
Git.
Thanks for the explanations.
--
Philip
---
This email has been checked for viruses by AVG.
http://www.avg.com