Currently, the #region and #endregion tags are treated as part of the comments for the method that occurs after them. As such, if you organize your code with these #region sections, and then you happen to move a method just below a #region to a different place, and then you have a merge conflict over that method, then the regions get messed up.10 votes
I'm in the process of creating support for Clojure. If I opensource it, may get the licence for my team please?1 vote
I think that the comments should be treated as a separate category of changes. That is, we have sections for Added, Removed, Moved, Changed. I would think it useful to have a Changed Comments. This is worthwhile because comment changes are much less important than code changes. If I do a lot of documentation changes, and in the same commit I happened to make a small code change (intentionally or not), I want that code change to stand out. The documentation is not nearly as important as the code itself.7 votes
Maybe many will is interesting to compare files in your application. Is it possible to create a new product in the form of control for the .Net applications?
I apologize if this is a silly suggestion, but the market I have not seen something like that.
Thank you.3 votes
README.md files and more are pretty common to store in source control because they generally work better in line-differencing environments than most other formats. However, adding a word to a line and reflowing a paragraph still results in more noise than actual, functional difference between the content with traditional differencing tools. Using the CommonMark AST, differences would be far less noisy.9 votes
It would be awesome if you created an open core product so that others could contribute to the merge algorithms, port to external IDE's, and add support for additional languages.6 votes
NuGet package files are simple XML files, and the merge procedure should be reasonably simple too.
Packages are keyed by ID, so if there's a collision based on the ID, take the package reference with the highest version number.
If the two sources include unique packages, the result should be the union of the two.3 votes
on semanticmerge.com is no explanation how to integrate it into visualstudio and/or beyondcompare.
this might be a good tool but without thorough explanation on how to integrate it into my and my colleuges working desktop it's just a useless nothingness.
best would be you get your a$$e$ up and create an automatic installer that fully integrates semanticmerge into common configurations.
i'm working for a global player company, hundreds of devs only in the branch where i work, but they don't buy licenses because of this!
think about it $$$...1 vote
Typically when rebasing in git, there will be a ton of trivial merge conflicts where I have to click Save & Exit in the GUI on each and every one.
I believe there was a --slient flag at one point, but I never worked and I can no longer find documentation on it. Running 1.0.80.
--slient together with -a (automatic merge) would ideally do what I want.
My .gitconfig is as follows:
cmd = \"C:/Users/Andreas/AppData/Local/PlasticSCM4/semanticmerge/semanticmergetool.exe\" -d \"$LOCAL\" -s \"$REMOTE\" -b \"$BASE\" -r \"$MERGED\" -a --nolangwarn --silent
trustExitCode = true6 votes
If a method, field, or property is renamed, the tool understands this and lets you know it was just a rename. However, it still flags every place in the code that references that item as a change. This seems like a simple thing for the tool to recognize and filter these out.
Renames (especially in Visual Studio) are done in an almost guaranteed bug free way. So, I would love to not have to see them in diffs at all.14 votes
Currently (for some time now) when running 'update' in aptitude the following error is reported:
A: GPG error: https://www.semanticmerge.com ./ Release: The following signatures are not valid: KEYEXPIRED 1442157655
Of course, this has nothing to do with 'aptitude'.
A new key needs to be provided and packages need to be signed with that key.
The way Debian and Ubuntu do this is to have a separate package which is signed with the old key, and, when needed, delivers the new keys, then, after that package is available, the new key can be used for signing.3 votes
Go is a very small and simple language with easy rules for packages and visibility. Growing rapidly in popularity as well should make it a good target for semantic merge.23 votes
Everything works great for C#
Sometimes, however, semanticmerge makes my code ugly like the screenshot I attached.
It seems it has some problem on tab character merging or my fault.
any idea?2 votes
Provide a nice view of the changes in project.json files that are the new standard for DNX development.
Not looking for generic JSON support, just for the project files (although I wouldn't complain...)1 vote
When a conflict is resolved, it still uses a red color in the scroll bar, meaning there's no easy way to check which ones are solved and which aren't.4 votes
Right now, it's hard to check which block was selected as part of a review: you have to select the block and then look at the bar above each panel. Maybe some symbol could be added to the scrollbar.6 votes
Right now, it's a little confusing to check which block is being currently reviewed in the merge tool (or on the diff tool). Only colors might not be enough, or, maybe, changing the color on the scroll bar may be the solution.6 votes
If the selected changeset removed something and added something else, the result file panel will show the old line with a strikethrough. That's a bit counter-intuitive, IMO, for I want to see the actual result (which wouldn't include any removed lines).3 votes
- Don't see your idea?