Hi, Jeff. JK> For example, if you have the content: JK> foo(); JK> bar(); JK> baz(); JK> and one side makes it: JK> foo(); JK> x = 1; JK> bar(); JK> baz(); JK> and the other side does: JK> foo(); JK> bar(); JK> y = 2; JK> baz(); JK> you _could_ argue that those changes are independent But it's close JK> enough that there's a good chance the two need to be reconciled, JK> and a human should at least take a look. You are right and your words make sense. But this thought may apply for this: We have one method/function about 200 lines. One author make change at line 1 of this method and other on 199 line. Both changes are done in one method so **human should at least take a look** Example 2: one author make change in method 1 second author make change in method 2 Method 1 is called from method 2. Those changes work fine on its own branch and does not work together. **human should at least take a look** This task is not for human and must be left for test system. So your example and two mine must not rise conflicts. This make useless noise. Another example of useless merge conflicts A--C--C'--F--? master \ \ / B--C--D--G feature Here I start branch feature. While developing update my branch from master by (C) changes While developing feature (C) were changed by (C') on master When I merge feature branch back to master I will get merge conflicts on lines in patch (C). I am not author of (C) and I do not care about it. Even more I can not care and must not. Implemented option (like --theirs in last example) to not be so conservative and do not rise merge conflicts for enough close changes will be good. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html