I encountered on several occasions already that what was displayed in pending changes did not match the actual state of files being committed. The reason being that changes are not automatically updated in the UI, but upon commit new changes are automatically collected using default behavior of changed files being committed, added, moved and deleted files must be selected manually - meaning the latter will not be part of such commit. The minimum thing that could be done is to notify the user that there are undisplayed changes that need to be reviewed. Even better would be to add git like staging of changes. I concede that this issues don't occur often and are a case of user being sloppy, but I would also point out that the workflow imposed by the UI doesn't help the situation. In my opinion gitextensions solves this problem nicely and clearly.

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.

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

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".

On merge arrows, we can click and get a tooltip of info (changeset and branch of source and destination, respectively). We can also right-click and choose commands "Go to source/destination changeset".

I suggest making the "cross-branch changeset links" (branch base/parent & child relation lines) clickable in the same manner.

You could display the following tooltip info:

• base/parent changeset number,
• base/parent branch name,
• child branch name

Also, you could provide the following right-click commands:

• Go to branch base / Go to parent changeset,
• Go to child branch

The first command would be much more intuitive than first locating and selecting the child branch, then right-click and choose "Branch Explorer - Go to branch base". And for the second command, there is no equivalent currently in the UI.

We have a very large tree of branches (when not applying filters) and navigating the branch explorer can be daunting sometimes. A single merge arrow or branch-relation line can stretch across several "screens" both horizontally and vertically. It's easy to get lost, especially since there is currently no way to follow a branch-relation from base to child, only the other way around.

Thus, the suggested feature would IMHO simplify branch navigation immensely!