Plans for improving semantic diff/merge

[dadhi]

Are the plans for instance to:

• Track the renames inside the method (C#)
• Combine multiple files as a one changed source, and track there the renames, moves, etc.
• Anything else on the topic?

[mig42]

Regarding the multiple files tracking, it's already there! Check this tour video on the topic: https://www.youtube.com/watch?v=5Omvx5PQ5kk

About the method body refactoring, the semantic diff/merge has the same features as our standalone tool semanticmerge. We had no previous plans to extend the semantic analysis to such fine grain as it might be overkill, but it's worth considering!

[psantosl]

This is a super interesting topic.

1. Track renames inside methods => do you mean variable renames and so on?

2. Combine multiple files? Can you elaborate more on this? I mean, we already track moves between files, and merge them.

3. Yes, there's much more on the topic. One idea we have in mind is tracking moved fragments of code, not only full methods. Like you move a part of a method to a different one, and still be able to diff it.

Another thing we have in mind is adding method history, something we have in Plastic SCM too: http://blog.plasticscm.com/2010/12/announcing-method-history.html

And some sort of full repo parsing, to be able to calculate the semantic history of methods but cross-file.

[dadhi]

do you mean variable renames and so on?

yes

I mean, we already track moves between files, and merge them.

Missed it, will check a demo mentioned by @mig42

semantic history of methods but cross-file.

Cool! That's what I meant

[psantosl]

@miryamGSM what do you think about variable renames?

We always thought it could be a little bit out of scope, because you end up with an endless chain of complexity to deal with (if/elses, etc). I mean, right now we handle the code structure (classes, methods, namespaces, etc) but the bodies are just text. This greatly simplifies things.

Going one step further and actually dealing with what's inside the method is always an option.

@miryamGSM and Violeta are our experts on this :)

[dadhi]

May be I was too general regarding variable rename :/

I want at least to start with method parameters tracking. Lately I had a merge problem when someone renamed parameters plus did other changes with the parameter handling. On my side, I have changes as well.

When you look at such conflict first, you see a mess. Only after you understand that it was just renamings, the rest to resolve just a few changes in logic.

[psantosl]

@miryamGSM and @violetaGitHub are our experts here. They can share some of their thoughts on the matter :-)

[violetaGitHub]

I'm completely agree that detecting renames will help a lot. But we must check first what's the cost... I mean, as you also said, after you understand that it was just renames, solving the conflicts is trivial. We don't discard to include this in the future :)

For the diff, we have in mind other ideas as distinguish files with changes only in "usings". When checking branch diffs, sometimes you find there are more than one hundred files modified. You start to "sweat" before you start reviewing the changes :S But, once you start navigating through the files, you see just few of them have "real" changes, the rest are only changes in "usings". We think it will be really helpful for reviewers to separate in a different category those files or mark them somehow... What do you think? Did it ever happen to you?

[dadhi]

distinguish files with changes only in "usings".

Not sure that I've got it.

From my experience the large amount of changed files happens when you rename a cross-cutting, infrastructure thing. For instance, if in C# I am changing name of namespace, then all files with this one and child namespaces will be changed.

[dadhi]

Actually, just yesterday I did architecture refactoring by rearranging the projects and renaming the namespace.

I have renamed Foo.Bar.X into Foo.Bar.Y. The result is 72 changed files that had a using Foo.Bar.X.

Semantic Merge actually said that it was Remove/Add change instead of Rename.

Just imagine how cool and life simplifying it would be, if the rename was detected across all the files. Just saying :)

[violetaGitHub]

Yes, this is what we want. SemanticMerge would prevent you from having to check those files :) We will try to work on it soon. Thanks for your feedback and suggestions!

[dadhi]

@violetaGitHub Great to hear, thank you!

[psantosl]

@violetaGitHub but why it sais remove/add instead of rename?? Why doesn't it detect the rename?

[violetaGitHub]

SemanticMerge doesn't detect renames in usings. We could detect it if the rename of the namespace was considered for the usings across all the files.