Skip format conflicts with the new SemanticMerge 1.0.64

Skip format conflicts with the new SemanticMerge 1.0.64

Friday, May 16, 2014 0 Comments

We switched to the latest open-source Roslyn in the previous release and now we’re adding more features based on that.

This new release includes 2 major features:

1. Automatic method body merge resolution with the --merge-decl param: so far if a method (or any declaration body) was modified by the two contributors, the user had to manually launch the external 3-way merge tool to solve the conflicts, even when the merge was automatic. Now the new param forces Semantic to try to solve every method body so now the merge is as automatic as possible.
2. Skip code formatting conflicts: suppose two developer reformat the same method but only one of them introduces an actual change. It can be time consuming to figure out that the change was only a reformat and that nothing really changes before accepting the real change. This is exactly what the new feature does for C#. It solves 3 User Voice requests:
   • http://plasticscm.uservoice.com/forums/196398--mergebegins/suggestions/3986679-semantic-merge-needs-to-be-smarted-about-unimporta
   • http://plasticscm.uservoice.com/forums/196398--mergebegins/suggestions/4124571-ignore-whitespace-around-curly-braces
   • http://plasticscm.uservoice.com/forums/196398--mergebegins/suggestions/4416982-format-code-to-every-user-s-liking-and-end-the-end

Remark: If you want the advanced feature related to the ignored format available for .net languages, you should download the Microsoft Build Tools 2013: http://www.microsoft.com/en-us/download/details.aspx?id=40760

Automatic resolution of conflicts inside methods*

(*Methods or any other declaration body).

Consider the following scenario:

>

Where the method “CheckParentsFromDstMergeLink()” was:

• moved to a different location by the first developer and also modified (that’s why the icon is ‘c’ and ‘m’ (changed and moved)).
• changed by the second developer.

And the changes were as follows:

Since the changes were made on non-colliding lines, the merge can be fully automatic.

Adding the new param --merge-decl (which stands for merge declarations) Semantic will still show up showing the method conflict as solved:

If you also add -a (which stands for ‘automatic’) the GUI won’t be launched and the result file will be directly created (for files with conflicts that can be automatically solved).

Skip code formatting conflicts

This is the most important feature we have introduced in the last months: it really takes advantage of ‘understanding’ the underlying code structure to automatically solve as many conflicts as possible.

Suppose you’ve a method like this one:

>

Then one of the developers starts working and moves the method to a different location within the class (like in the previous example). But he also makes some changes to the code:

Meanwhile a second developer makes some changes to the same method too:

As you can see they both made a non-colliding change which is adding more log on different locations, but then there’s a colliding change: the two modified the method declaration: one added a new param while the other reformatted it. While easy to handle for a human, every 3-way merge tool will end up with a conflict because it can’t decide what to do:

But Semantic, with the --merge-decl argument is able to automatically solve the conflict as follows:

Semantic basically knows the ‘reformat’ change can be discarded and then re-runs the text merge.

Next steps – improving ‘ignore reformat heuristics’

Well, ignoring format changes during merge (or diff) can greatly help saving precious time without being distracted by trivial changes.

That being said, code formatting is crucial for readability, so there will be many situations where you’ll want to preserve the formatting.

In the case above Semantic made a decision: since undoing a format change avoids a time consuming (ok, not so time consuming this time, but you get the point) conflict resolution, Semantic will just undo the change to simplify the merge.

Our goal is to make Semantic smart enough to avoid only the minimum number of reformats, so that the code preserves the preferences of the author.

While it is still definitely work in progress, we’re happy to say that Semantic is able to do things beyond what any other diff or merge tool can!

Enjoy!

The SemanticMerge team