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 users will understand what you want.


Follow the stackoverflow.com writing guidelines.

Thank you for your help!

+9
Completed

Output window: add date and time stamps for events

David 6 years ago updated by Thomas Singer 4 years ago 7

To aid in diagnosing merge issues and checking when events occurred add the date and time stamp to each node in the output tab

+9
Completed

Changes view: allow staging/unstaging in "compact changes display", too

Femistoklov 7 years ago updated by Thomas Singer 3 years ago 4

The rows can be reverted only in standard changes view, not in compact one. I don't know, if it is because of any technical 

+9

Log: allow searching using logical operators

Christopher Kline 7 years ago 0

I would like to be able to filter the log using logical operators. For example, I'd like to perform searches like:


"crash +startup +UI"

"settings -frontend"

"<my user name> +merge"


etc.


Basically I want to be able to combine search terms using logical "and" and "not" operations, so that I can filter the log down to only the specific commits I'm interested in. 


Currently this is not possible, and makes it difficult to find a particular commit. For example, searching for my user name might turn up thousands of commits, but searching for my username AND "crash" will filter that list down considerably.


This is a simpler version of a far more complex request that has been open since before SmartGit had this UserEcho site (see Log: filter query language [SG-10517])


+9

Submodules: Reset multiple submodules at once

Dorn 7 years ago updated by Arno Baumfalk 1 year ago 6

if your submodules fail to check out - you have 2 reset each one by hand instead of resetting them all at once

+9
Completed

Add full support for shallow clone workflow

Christopher Kline 7 years ago updated by Thomas Singer 3 years ago 4

Shallow repos are extremely useful when working with huge repositories with long histories and large amounts of data (like binaries).


Since git 1.9 (with better support since 2.5), git has fully supported shallow repos (you can push/pull to/from the remote, etc), and is now very configurable. This lets developers pull down only a small amount of the history, making it faster to work locally (due to less data in the repo that needs to be maintained), and also avoiding the need to pull huge amounts of data over the network when cloning.


SmartGit currently has an option, when cloning a repo, to clone only to a specific depth. However, this is not sufficient for fully supporting a 'shallow repo' workflow, for the following reasons:

Missing functionality:


  • If you wish to clone to a specific depth, you only have the option of doing so if you un-check the "fetch all heads and tags". There is no support for fetching all heads so long as they are within the desired commit depth (the "--no-single-branch" option in 'git clone').
  • No support for choosing --shallow-submodules vs --no-shallow-submodules when cloning.
  • There's only an option to clone to a depth, and not "clone since date" (the "--shallow-since=<date>" option in git clone/fetch)
  • No support for --shallow-exclude in clone/fetch/pull
  • No way to change the desired depth after cloning (that I could find), to use subsequent fetches/pulls to trim or fill-in the history
  • No support for --unshallow, --update-shallow, or --deepen-shallow when fetching

Bugs (as of SmartGit 17.1 preview 6 #11041):


  • Regardless of what depth you clone to, when SmartGit does a subsequent fetch, it does not specific the desired depth, so you end up pulling the entire repo anyhow. This defeats the purpose of a shallow clone

This request is similar to https://smartgit.userecho.com/topics/395-implement-a-light-version-of-repository-management/ but expands upon it significantly.

+9
Completed

Add support for gitflow-avh

Kevin 7 years ago updated by Marc Strapetz 4 years ago 11

gitflow's last update was about 4 and a half years ago. It's no longer maintained so no new features and more importantly no bug fixes. gitflow-avh is the most popular fork of gitflow and remains active to this day. According to the author of gitflow-avh both Debian and Ubuntu have switched to his fork to provide the git-flow package which is a very good indicator that the original project has died and that AVH is a suitable alternative.

+9
Completed

Add option to find common ancestor (aka merge base) for selected commits

Mikhail Matrosov 7 years ago updated by Marc Strapetz 3 years ago 3

Investigating history of commits with many merges can be a real pain. One useful feature is to be able to locate merge base. Not only for merge commits (though it would be useful on its own), but also for arbitrary pair of commits.

+9
Completed

Shift+Scroll To Scroll Sideways

Colin Richardson 7 years ago updated by Ondra Komárek 11 months ago 6

On browsers (well, atleast in chrome), if you have a really wide webpage (Trello for example) You can use Shift+Scroll to scroll wideways rather than up and down.


It would be nice if I could do this on Compare Panel too. For comparing long lines of code.


Not normally a problem, but I have a monitor in portrait orientation, and if you are using Index Editor, it doesn't leave much room. I just noticed it was missing was all.

+9

Option to disable all notifications from syntevo but updates

Kanstantsin Kamkou 7 years ago updated by Thomas Singer 5 years ago 9

Please allow paid versions to ignore all synteo messages (help us to improve ..., a new beta versions..., etc.).

+9
Completed

Rebase by default when pulling

Pierre Goiffon 8 years ago updated 7 years ago 12

For a fresh new SmartGit install in my team, we always need to change the default pull behavior : doing a rebase with local changes instead of a merge commit. The later produces absolutely unreadable logs and I think for the vast majority of users is an aberration.

So I'd suggest to change the default value, or make it configurable as soon as clogin / opening a new repo.