Share your ideas on how to improve SmartGit!
This is no support platform! To report bugs or request support, please contact us directly. If in doubt ask us.
First search for a similar request and add your votes or comments there.
Take the time to describe your request as precisely as possible, so users will understand what you want. Please note that we appreciate your time and input, but we don't give any guarantees that a certain feature will be implemented. Usually, a minimum requirement is a sufficient number of votes. Hence, please don't comment like "when will this be implemented", but vote instead.
Follow the stackoverflow.com writing guidelines.
Thank you for your help!
Add panel exposing the CLI (bash/cmd)
Add a panel that will be exposing the OS CLI opened in the project's folder.
Better support when using SmartGit for Git and Mercurial at the same time
I use SmartGit for both Git and Mercurial, which is great: I have just one tool learn, and the same tool on Windows and on Mac. But, the commands and preferences for the two VCS are inconsistently implemented. For example:
The preference "Stash: Automatically save stash if Pull, Checkout, or Interactive Rebase fails because of local changes" works for Git but not Mercurial. Similarly, the Apply patch menu item uses the git apply command rather than the Mercurial import command even when pointing to a Mercurial repository.
SmartGit should be smart enough to know what sort of repository it is executing against and use the appropriate command, or tell us when that command hasn't been implemented.
Also, perhaps there needs to be separate preference tabs for Git- and Mercurial-specific preferences as there are some siginificant differences.
Mercurial: support for creating and importing patches
SmartGit allows you to create and apply a patches for Git, but not for Mercurial. Atlassian's SourceTree and the tool within Intellij IDEA have a context menu against log entries to create a patch from single or multiple commits.
Log: custom tools should work on Files (as in the main window)
Tools configured in the Preferences should work on the Log's File view in a similar way as in the main window
Allow checking a branch folder
We can check individual branches, and view their commits, but I would like to be able to check out an entire family of branches, grouped by folders.
Implement "flashing on taskbar" red/orange highlighting to make user aware of failed Git operations
When a Git push fails e.g. due to a server side error (e.g. "non-fast-forward") while SmartGit is minimized (I often click push, then continue working on the next topic), the icon of SmartGit does not show that a problem occurred on Windows, it looks totally normal:
![]()
For that reason, it is easy to miss that there was a problem with the attempted operation. Only when clicking on the SmartGit icon in the taskbar again, the problem becomes apparent:

Windows has a feature called "flashing on taskbar" which will make the icon display in red/orange to make the user aware that the app requires his or her attention. Would be great if SmartGit could implement to activate this when the error view opens up.
Add Configurable Pattern Matching For Feature Branch Detection in Forced-Push Settings
It appears that SmartGit only supports strict Gitflow naming conventions for the setting:
“Allow modifying pushed commits (e.g., forced push): Only for feature branches” (see Preferences dialog below). Currently, this option recognizes only branches that begin with the standard prefix, for example:
- feature/my-feature.
However, Git supports hierarchical branch naming, and many teams organize branches using developer or team namespaces, such as:
- jmt/feature/my-feature
- teamA/feature/my-feature
- dev123/feature/some-feature.
These branches are not recognized as feature branches under the current implementation, and therefore are prevented (see Push warning dialog below) from performing forced pushes unless the more permissive “For all branches” option is selected. This introduces unnecessary risk by enabling forced pushes across all branches rather than restricting them to intended feature branches.
Consider adding support for configurable detection patterns (e.g., wildcard or regex) for the “Allow modifying pushed commits” option. For example:
- feature/* (default, GitFlow)
- */feature/* (namespaced branches: jmt/feature/foo)
- */feature-* (flat naming: jmt/feature-bar)
This would preserve the existing default behavior while allowing greater flexibility for teams that use developer, team, or other namespacing conventions in their branch structures. This enhancement would enable safer and more precise control over forced push permissions without requiring teams to abandon established branch naming practices.


Customer support service by UserEcho