When selecting two changesets on two different branches and choosing "Diff selected changesets", the resulting Changeset Diff view can contain identical files (files that do not differ at all between the two changesets). This could happen if the same change has been applied to a file on both branches, without a merge.

In this case I suggest that the identical files be hidden from the Diff view. The whole point of a Diff is to see the files that differ, not the ones that don't.

(NOTE: In my case, I had loads of identical files due to an import from Subversion via GitSync where some merges were not fully registered as such.)

The "cm patch" command is able to yield diffs in the standardized "unified diff" or "unix patch" format as console output. However, there is no simple way to yield the same kind of console output for the Pending Changes.

Our Linux users are demanding this, and they are surprised that it is not currently possible since they are used to this behavior from "cvs diff", "svn diff", "hg diff" and "git diff".

We suggest adding this functionality to the "cm patch" command. All that's needed is to output the same kind of "unified diff" as usual, but based on the diff of the current pending changes in a workspace. Either by adding another option flag to the "cm patch" command, or by simply calling it without arguments.

If you are in a branch with some un-submitted files and you don't want to submit them into your branch yet. If would be great to be able to select the files you want and submit them directly into another branch but keep you in your existing branch. We work with not allowing people to switch branches with pending changes so 'Check in to another branch' doesn't work unless we manually switch to allowing you to switch branches. Then once the files have been submitted to another branch you'd then have to switch back to your previous branch ready to carry on working on the other un-submitted files you have and switch the option back to don't allow changing branches with pending files.

Way back when I still used TortoiseSVN, I really enjoyed the fact that it's commit comment textbox would suggest types and filenames when committing new changes. See the attached image for an example.

The simplest implementation would be for the client to check the pending changes, compile a list of the filepaths and filenames, and then determine if the current typed word would match one of these list entries. If a word partially matches one of the entries, show a dropdown of these entries to let the user choose or dismiss the entries.

Just to elaborate, this is not an auto-fill feature (like #6389015), but more an autocomplete used to aid in comments like "VirtualFileBrowser now caches previous opened items" or "Removed Delete method from AbstractObjectCollection".

Now, the update triggers only provide a path to the workspace being updated.
Having access to the old and new changeset-id's opens up quite a lot new possibilities.

For example, in UE4, when working with plugins in a code project, they are compiled automatically at first. When making code changes to the plugins, they are often not automatically detected which causes the engine to crash at startup.
Deleting two specific folders makes the engine recompile those binaries automatically and thus fixes this inconvenience. Unfortunately, this process takes about 5 minutes on average so doing it after every update is not feasible.
By providing a specific string/tag in the comment of checkins that require a compile, we are able to only recompile when necessary.

In order to make this work, we have to write out the current changeset-id to a file in the before-update trigger. Then in the after update trigger, we get the current one. Finally we would use the find command to get all changesets in between those two and check if any of their comments contain the tag.

We are already able to access the current changeset-id with
cm status --nochanges
and some parsing. (Although this could be made easier.)
Thus, only exposing the future changeset-id in before-update and the previous changeset-id in after-update would suffice.

Thanks in advance