please run a simple diff with semanticmerge
It will tell you that the include <...> has been changed, not the comment4 votes
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
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
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
I would love to use this with my favorite IDE!6 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
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
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
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
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
You've stated in a previousl request that you will allow us to request as many additial keys as we need since many of us have mutiple machines. Tha is an OK work around for now, but the request process is too cumbersone. ON top of that, if we reinstall Windows or get a new machine, which my team does often, then we need to request a reset of that key via email. This process needs dramatic improvement. At the very least, we need the ability to reset our own keys via the web interface and as added functionality, just allow us to create up to 3 per license...which should cover the multi-device issue for now.
You've stated in a previousl request that you will allow us to request as many additial keys as we need since many of us have mutiple machines. Tha is an OK work around for now, but the request process is too cumbersone. ON top of that, if we reinstall Windows or get a new machine, which my team does often, then we need to request a reset of that key via email. This process needs dramatic improvement. At the very least, we need the ability to reset our own keys via the web interface and as added functionality, just allow…9 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
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
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
Be able to view unified diff-files directly
you should be able to directly take a look at unified diffs.
if you run the command "git diff <commit>...<commit> >> changes.diff" you should be able to directly open that .diff-file. this would be really convenient.
tortoiseSVN merge/diff for example is capeable of doing that.11 votes
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
When blocks differ in number of lines, they aren't correctly aligned in the panels. Where new lines were added/removed, blank lines should be displayed (like BeyondCompare does) which helps comparing line-by-line.9 votes
- Don't see your idea?