Git Merge: parallel identical additions are merged without conflict by including the same code block TWICE in the merged file without complaint. Why?

Question

I have a slightly tricky history in my Git log that I am trying to understand fully.

Before explaining the sequence of commits, let me paste images of the Git log (using

Answer 1

It's pretty simple: when doing a merge, git analyze the lines that have changed on both size:

• If the changes are less than 2 lines apart^{(Reference is coming soon)} this will create a conflict, since the changes are very probably about the same thing;
• If the changes are more than 2 lines apart the content from both side is considered as two different things and the content added is not analyzed, just added to the resulting file.

Since LHS added the function on line 79 and RHS added it on line 69 git thought that it was different content as it was more than a very few lines apart.

---

How to avoid this in the future?

• Proceed to a diff between the two branches, this will be visible if you read your diff carefully and then edit it in the merge;
• Communicate more within your team (if possible), is this normal that two developer wrote the exact same function in two separate branches?

---

From the git merge doc (emphasis is mine)

HOW CONFLICTS ARE PRESENTED

During a merge, the working tree files are updated to reflect the result of the merge. Among the changes made to the common ancestor’s version, non-overlapping ones (that is, you changed an area of the file while the other side left that area intact, or vice versa) are incorporated in the final result verbatim. When both sides made changes to the same area, however, Git cannot randomly pick one side over the other, and asks you to resolve it by leaving what both sides did to that area.