Git three-way merge: A single line is changed in branch one, & not in branch two. Why does the changed line trump the unchanged line?

Question

I'm reading Pro Git. You're working on branch named issue53 when the boss tells you that there's a crisis on master – a typo. You commit issue53, check out master, create a new hotfix branch, fix the typo, and then merge it back into master.

You then go back to issue53 and continue your work. When you're done, you do a three-way merge back into master, the goal being to eliminate the issue53 branch.

The typo-fix from master now takes effect in the merge result.

My question is this: How does Git know that the fixed typo in master (a single change on a single line) is "more important" than the non-fix in issue53? I would think it should ask which version trumps the other (create a conflict resolution marker:resolution marker "<<<<< ...").

Answer 1

I guess that change takes precedence over status quo. I.e. if one version has the line changed, and the other does nothing, the result is the change. I'd say that's the main principle of three-way merge.

Manual conflict resolution takes place only if both versions are changed in some way.

To test this, I created a repository with one simple file, and made two branches. I edited some lines in both branches, and then merged the changes together. This is the result when opening diff resolution tool:

As you can see, places where only one version was changed got resolved automatically (and the change got precedence), the only place where manual resolution is triggered is the last line which was changed in both branches.

Answer 2

After doing some further reading, my current understanding is this:

Because of the resolution strategy Git uses (scroll down a bit on that page), the currently-checked out version (this: master) trumps the other (that: issue53).