We never use merge except fast forward merges. So we never have merge conflicts.

Of course that means that we might need to rebase and that could hit conflicts. With diff3 style rebase conflicts are generally [1] easy to understand. When a commit does not apply cleanly the diff3 style output gives you 3 sections:

1. What the code looks like after the previous commit that has already been rebased to the new branch under work

2. What the code looked like in the original branch

3. What it looked like 1 commit later in the original branch.

Now the question the human is: You (or some one else) changed it from 2 to 3 in the past. Now your code is not 2 but 1. How do you introduce an equivalent change from 1 to something that works like 3?

Once I have learned that principle I could no longer understand why diff3 is not the default or how anyone can survive without it.

[1] Of course there can always be tricky changes. If an automatic diff tool choses unlucky alignments the result is not ideal for humans. But diff3 does not make things worse and generally it does not happen that often.

Edit: A couple of iterations needed. Don't try to type somewhat complex comments on your phone...