Merge: contiguous automatic conflicts produce a non automatic conflict?

Merge: contiguous automatic conflicts produce a non automatic conflict?

Monday, March 21, 2011 Dave merging 0 Comments

A few weeks ago, we received a support ticket showing a pretty specific merge case where our mergetool was prompting the user to resolve a non-automatic conflict. The changes on the source and destination revisions were on separate sets of lines, so at first sight they should be merged automatically. But the changes where contiguous. Let me show you the case:

The files I used are not related to the original question, but the case is the same. The user pointed that p4merge was not detecting conflicts and performing the merge automatically:

So p4merge is making your life a bit easier than Plastic's mergetool by doing some automatic operation for you, right? It's fine for a case like this. But let me show a similar example, this time with code.

Here is p4merge, with changes in separate lines of code on the source and destination and identifying both of them as separate changes. The merge is automatic:

However, looking at the result file, the code there is not likely the intention of neither of the developers. Now let's see how Plastic's mergetool does it: 

In this case, mergetool is again detecting a non automatic conflict, but in this case, this is a better option, since the incorrect automatic result would otherwise remain unnoticed.
This is so because when dealing with code the context is important, and Plastic will check the context of the conflicts to determine if a situation can cause potential "merge pain". On that situation, the rule is "better ask than automatically resolve something potentially dangerous".