3-Way Merge in git - how comparing works

Question

I have three versions of the file:

version 1       common ancestor      version  2
-------------   ---------------      ------------- 
before          original line        original line
original line                        after

What happens while comparing these versions to produce final merge version ?

I have read some information about this topic, but I am still confused how exactly it works.

As for latter example:

Is comparing individual lines between versions linear ? If so, then final merge should look like this:

1 line: before
2 line: conflict (both left and right contributors are changed compared to ancestor)

Is this correct understanding or does it work differently ?

You can simply try this out. Create a repository and make an initial commit with a file that has a bunch of lines. Make a branch (or two if you like). Check out a branch and modify the file to add a line above, then add and commit. Check out the other branch (or the master) and modify the file to add a line below, then add and commit. Then ask Git to merge, and observe the result. See also https://stackoverflow.com/q/44359334/1256452 — torek, Jun 23 '17 at 14:44

score 7 · Answer 1 · answered Jun 23 '17 at 14:41

A three-way merge usually means that instead of just comparing the final result to perform the merge, the common base version is already being looked at. What Git then does is create a representation of changes for each version.

So what it actually gets, relative to the base version, is the following:

version 1           version  2
-------------       -------------
+before              original line
 original line      +after

It will then use common lines as context to align the changes:

version 1           version  2
-------------       -------------
+before
 original line       original line
                    +after

At which point, the merge is easy to resolve without a conflict to the following:

before
original line
after

Note that such a merge may still result in a conflict because Git might not have enough common content to align the changes properly. Especially for very small files this might happen.

score 3 · Answer 2 · answered Jun 23 '17 at 14:41

I don't think merge is done by "comparing" individual lines straight between version 1 and version 2. It's more involved than that. It's about trying to see where the diffs between common-ancestor..version1 and common-ancestror..version2 can be "merged". In your particular case, there's a single line on the original version, right? I think that if the line had an EOL at the end before the EOF, then merging them won't break (because that line would be present on both final versions) and so it would be merged perfectly fine. However, if the line did not have an EOL at the end, then version 2 would have removed that line (because the original line is not there anymore.... now it's a different line because of the EOL) and then you would end up with a conflict.

I just tested both ways and it worked just as I described. – eftshift0 Jun 23 '17 at 14:55 — eftshift0, Jun 23 '17 at 14:55

3-Way Merge in git - how comparing works

2 Answers2

Linked