Support merging across files
Right now the samples on the website about splitting up a class are a bit unrealistic since they all include splitting the class up but keeping it all in the same file. In reality, we often move code to different files and still want to merge. SemanticMerge will be revolutionary if it can solve this problem.
Giuliano B
shared this idea
Dear all,
We are happy to announce that we implemented your request of cross-file semantic merging.
It is really awesome and since strong git integration is a must, it is part of our new product: gmaster a full-featured Git client based on Semantic tech.
You can download it here:
And you can watch a video of cross-file merging in action here:
Enjoy!
-
David
commented
Any updates on this?
This is a common way-of-working and SemanticMerge would truly shine here.
Since SCM support will be needed, you can start with Git as the first "non-Plastic" option if only because it's free and already has good bridges to other systems.
-
Andrew Tatham
commented
This is my scenario....
Branch A has class A
I make branch B from branch A
On branch B, I move most/all of the code in Class A into a new base class.I switch back to branch A. I make a fix on class A.
I switch back to branch B. I want to merge the fix in to branch BBecause most of the code from branch A has been moved to Branch B's base class, I want the fix to be merged into the base class :)
but in reality I get a load of merge conflicts on class A :( -
James Woods
commented
The cross file merging would be great but for me the language sensitive cross file difference analysis would be the real benefit in that any large scale method refactors could be reduced to a single line saying that method was refactored.
-
Gerard Murphy
commented
Any progress on this yet? ... I saw the video that mentioned this last year, would like to give it a spin...
-
Gerard Murphy
commented
I've taken my 3 votes off the feature request: File "branching" to allow new file to track inheritance from previous file.
I've put them on this instead, as I think this is a much better way of handling the use-case of splitting files discussed in the other feature request.
-
Gerard Murphy
commented
Yes, in the past I voted for the ability to support file copies with history in Plastic - my use case was the splitting up of a single source file into multiple files during refactoring - so I could associate the split files with the original as modified copies. However, I'd much rather see semantic merge support this directly, in which case I probably wouldn't need the history-through-copy tracking any more.
What I had in mind was conceptually concatenating the files (sorted by name) in the before and after changesets into two 'virtual files', then having semantic merge automatically compare the two virtual files - so its code motion would generalise to detecting both file moves / renames as well as code splitting across several files.
-
psantosl
commented
Good point!
In fact we already have the solution in mind and it is pretty doable.
The only caveat is that implementing it with Plastic SCM (our own version control) will be a no-brainer but adding support for others will since we will need them to send us additional information and not only the conflicting files one by one.