Tools configured in the Preferences should work on the Log's File view in a similar way as in the main window

https://plugins.jetbrains.com/plugin/7566?pr=idea

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.

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.

Many Python users work with virtual environments (venvs), typically one per project. For pre-commit hooks to run correctly, the appropriate venv must be active; otherwise, issues such as missing modules can occur (e.g., Pylint will report "module missing" errors if the wrong venv is being used).

A workaround that currently can be used is to launch SmartGit via scripts individually crafted per project to activate the respective venv, e.g.:

call C:\Users\username\PycharmProjects\project_name\.venv\Scripts\activate  
C:\Apps\SmartGit\bin\smartgit.exe  

However, this is not a general solution, since SmartGit allows users to switch between projects within the tool, which leads to the wrong venv being used again. It would be great if there was a way to have Smartgit automatically activate the correct venv of the respective project.

Especially when pre-commit hooks are active, commits can take a couple seconds. Would be helpful to be able to abort the commit if you realize that you do not actually want to perform this exact commit while waiting for hook execution.

The "Log Window" and "Working Tree Window" allow flexible customisation of the layout, so why not the "Standard Window"?

The left sidebar uses a lot of dead space, taking the entire height, and I can't see checked-out branches and stashes at the same time.

I want to give some of that dead space to the Changes view, ideally the full width of the window (I prefer side-by-side diffs).

Given the recent slew of vulnerabilities in gpg (gpg.fail), al well as several years of recommendations by security experts (latacora, soatok), I'm currently phasing out gpg. In alternative to gpg, git also supports signing commits with SSH keys (gitlab, github).

It would be great if SmartGit could support SSH signatures.