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 precise as possible, so we (Syntevo) and other users will understand what you want. A plain request "SmartGit should look cool" is too vague because we don't know what we should change, and hence will not be approved by us.

Thank you for your help!


Clone: option which branch should be checked out

Marc Strapetz 1 year ago • updated by Thomas Singer 11 months ago 3

The Clone wizard should provide an option which branch should be checked out as a result of the clone. This will also affect checked out submodules.


Log: integrate into main window

Marc Strapetz 1 year ago • updated by Pierre Goiffon 1 week ago 27

Alternative solution

Instead of having a separate Log window, this should be part of the main window in order to have all functionality of SmartGit be available in a single window.

This would mean to add all views of the Log to the main window, duplicating a couple of them with slightly different meaning, e.g. the Changes view in the Log is purely read-only, but can show comments - the one in the repository window can be used to stage/unstage; the Files view in the Log does not allow any of the main window's commands; the Branches view in the Log allows toggling anchor commits for the Commits graph and shows additional items, e.g. recyclable commits. It would be a horrible amount of work and still would require stand-alone Log windows, e.g. for file or subdirectory logs.


Git bisect support

Daniel 1 year ago • updated by Thomas Singer 6 days ago 6

Support of git bisect functionality.


Changes view: allow editing file

vseticka.martin 11 months ago • updated by Thomas Singer 10 months ago 10

When I review changes that I'm about to commit I often find that I made a typo. I would like to make some adjustments in SmartGit right away to avoid navigating to the file in my IDE.


Add the ability to successively apply the conflict solver

Chris Jaquet 11 months ago • updated by Alexander Zhezherun 10 months ago 3

It often happens during a merge that a number of files in a repository will have conflicts. It is already possible to apply the conflict solver to individual files, but I would like to propose the following workflow:

During a merge when multiple files are conflicted:

  1. Select all the conflicted files.
  2. Choose to activate the Conflict Solver.
  3. For each file in the select list open the conflict solver (as is done for a single file)
  4. User solves conflicts (or decides to cancel), thus terminating the conflict solver for that file.
  5. SmartGit shows a dialogue with the following options "Stage file", "Skip file", "Cancel".
  6. "Stage file" will stage the file and SmartGit will automatically open the conflict solver for the next file in the selected list.
  7. "Skip file" will not stage the file, or mark it as resolved, etc, but will move automatically to the next file in the list, opening the conflict solver for the next file.
  8. "Cancel" will stop the process completely. Files already staged will remain staged.

This will, in my opinion, make merging multiple conflicted files much easier. There could also be a button on the ToolBar which starts the conflict solver for all conflicted files in the current repo, without the user having to select them all.


Commit IDs (SHAs) in commit messages should be hyperlinks with opens to view that commit

Christopher Kline 9 months ago 0

Often our commit messages refer to other commits, like:

"This commit fixes an issue introduced in commit 1d441145, which ..."


"59c5792d50c49f77ca9f044fa03c108c5f515de8 introduced a bug which caused ..."

Currently I have to manually copy the commit ID, then (opening a new log window first if desired) paste it into the log window search box.

What I'd like is a way for those commit IDs to be automatically highlighted, and when you right-click on them you get the option to reveal the commit in the current log or reveal it in a new log window.

To my knowledge, there doesn't seem to be a way to do this via the Bugtraq integration.


Gerrit as hosting provider

leuschns 2 months ago • updated by admin1 2 months ago 2

- add Gerrit as hosting provider

- config needed: server name, server port, optional path to ssh key empty uses default, like clone command that just picks up default file)

- connect to gerrit via ssh (command line would be 'ssh gerrit ls-projects') it responds with plain text, one repository name at a time

- clone URL becomes ssh://SERVER:PORT/REPONAME.git (append .git)

hosting provider

Visual Studio Team Services integration (like GitHub, Bitbucket)

hrant 11 months ago • updated by Alexander Zhezherun 7 months ago 2

Visual Studio Team Services is a popular and common tool among .net developers.

Although SmartGit can clone / pull ... from the Git repo, it is lacking proper integration similar to Github.

For example it would be desired to be able to do Pull Requests from within SmartGit, rather than jumping to another tool.


Prune merged local branches (e.g when fetching)

Theodoros Antoniou 11 months ago • updated by Andreas Völkel 11 months ago 4

When fetching from a remote, allow the choice to prune (delete) any local branches, which are tracking a remote branch that has been merged.

This is quite a common task, especially if you work in a team that uses a lot of feature branches and Pull Requests. Stackoverflow related question

P.s: This is a feature available in SourceTree.


Ignore File: ability to specify which .gitignore file to use

Chris Jaquet 11 months ago • updated 11 months ago 2

Having .gitignore files throughout a project's folders can make it difficult to manage the ignore rules for a particular project. It would be helpful when ignoring a file to be shown a dialogue which asks the user which .gitignore file to use - current folder (i.e. the folder containing the files to ignore) or repository root (the .gitignore in the root of the repository). An additional "nice to have" would be to be able to specify the default using a checkbox on the dialogue (as is done with the "Reset" dialogue in the log view.