Wikipedia says a 3-way merge is less error-prone than a 2-way merge, and often times doesn\'t need user intervention. Why is this the case?
An example where a 3-way
A three way merge where two changesets to one base file are merged as they are applied, as opposed to applying one, then merging the result with the other.
For example, having two changes where a line is added in the same place could be interpreded as two additions, not a change of one line.
For example
file a has been modified by two people, one adding moose, one adding mouse.
#File a
dog
cat
#diff b, a
dog
+++ mouse
cat
#diff c, a
dog
+++ moose
cat
Now, if we merge the changesets as we apply them, we will get (3-way merge)
#diff b and c, a
dog
+++ mouse
+++ moose
cat
But if we apply b, then look at the change from b to c it will look like we are just changing a 'u' to an 'o' (2-way merge)
#diff b, c
dog
--- mouse
+++ moose
cat
This slide from a perforce presentation is interesting:
The essential logic of a three-way merge tool is simple:
- Compare base, source, and target files
- Identify the "chunks" in the source and target files file:
- Chunks that don't match the base
- Chunks that do match the base
- Then, put together a merged result consisting of:
- The chunks that match one another in all 3 files
- The chunks that don't match the base in either the source or in the target but not in both
- The chunks that don't match the base but that do match each other (i.e., they've been changed the same way in both the source and the target)
- Placeholders for the chunks that conflict, to be resolved by the user.
Note that the "chunks" in this illustration are purely symbolic. Each could represent lines in a file, or nodes in a hierarchy, or even files in a directory. It all depends on what a particular merge tool is capable of.
You may be asking what advantage a 3-way merge offers over a 2-way merge. Actually, there is no such thing as a two-way merge, only tools that diff two files and allow you to "merge" by picking chunks from one file or the other.
Only a 3-way merge gives you the ability to know whether or not a chunk is a change from the origin and whether or not changes conflict.
Say you and your friend both checked out a file, and made some changes to it. You removed a line at the beginning, and your friend added a line at the end. Then he committed his file, and you need to merge his changes into your copy.
If you were doing a two-way merge (in other words, a diff), the tool could compare the two files, and see that the first and last lines are different. But how would it know what to do with the differences? Should the merged version include the first line? Should it include the last line?
With a three-way merge, it can compare the two files, but it can also compare each of them against the original copy (before either of you changed it). So it can see that you removed the first line, and that your friend added the last line. And it can use that information to produce the merged version.