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!

+1

Change "Reveal in Explorer" to "Reveal in File Browser" (at least semantically)

Matthias Wieding-Drewes 6 years ago 0

The context menu operation "Reveal in Explorer" does exaclty what it anounces to do--it opens the the folder conting the file using `explorer.exe`.

I however do not use the explorer.exe but 'Directory Opus' (DOpus). DOpus registeres itself as the default file browser and opens i.e. when I do a 'Open Containing Folder' in Visual Studio, or press Win+E.

Please do not default to the explorer, but instead use whatever indirection windows is offering and that DOpus hooks into instead the current way.

+1

Changes: prevent going to the previous or next file when the compare was forced

Iulian Onofrei 6 years ago updated by Marc Strapetz 6 years ago 0

In other words, if you:

- Select a big file
- Click the "Force Compare" button
- Use the "Go to previous change" or "Go to next change" buttons until you reach the start or end of the file

it would be nice if SmartGit wouldn't select the previous or the next file. Because then you have to wait again for the compare to be computed for the big file.



+1

Changes view: when you cannot show the change (diff) of a large (big) file, show the output of `git diff` for that file

Paul Thomson 6 years ago updated by benblo 6 years ago 1

Instead of only showing "File is too large to display.", could you please add the output of git diff for that file (perhaps just the first 10,000 lines/characters)? This at least gives *some* information.

There is also a delay before the "File is too large to display." It would be great if that delay could be removed, perhaps by estimating whether the file will be too large based on just the file size.

I work in a repository where there are several large files that must be updated in almost every commit, but the changes are tiny; just being able to see the change quickly would be ideal. 

+1

Please, stop closing the Base Changes window, when I close the Conflict Solver Window

Bugged 6 years ago updated 4 years ago 1

This started happening after the latest update: 19.1.1 #14179

After I open the Conflicts Solver window:

Image 383

I also open the Base Changes window:

Image 384

And when I think I am done, I close the Conflicts Solver Window.

But now, Smartgit is automatically closing the Base Changes window when I close the Conflicts Solver window. Very bad! How can I post review changes now?

I would also like to ask to:

1. Not close the Base Changes window, just because I closed the Conflicts Solver window.

2. Allow me to reopen the Base Changes and or the Conflicts Solver window, after I marked the conflict a solved, so I can refix something I bad merged/fixed on the last time I had those windows opened. Now, I can only do that by aborting the whole merge process and starting everything from scratch.

+1

Allow to reload changes on the `Conflict Solver` window

Bugged 6 years ago updated 6 years ago 0

Most times the conflicts I solve are so hard to deal with, I have to open the text editor to properly deal with them (like rewrite code).

Image 382

But when I go back to the Smartgit `Conflict Solver` window, the changes in the file system are not reloaded. 

It would be very welcome if Smartgit asked me whether I would like to reload the changes on the file system
.

+1

Dont make reset to hard reset

Jacques 6 years ago 0

Why oh why did you make the Reset command now become a hard reset? I never do a hard reset always a mixed one, and because of your changes, I have now lost a whole day's worth of work. The default reset should most definitely be the safer option of mixed so that you still have your changes

+1

Log, Branches: allow to select two refs in Branches view and immediate reveal both of them (easier diff between two tags)

Christian Bulitta 6 years ago updated 6 years ago 1

A (very small) improvement for the tag-diffs:It would be great to do the following:

  • Select 2 (or more) Tags
  • Reveal (from context menu)
  • expected:
    • Selected 2 (or more) commits are revealed
    • diffs are shown in case 2 commit are revealed


This would be the perfect UI for me to diff tags, especially if commits are far away from each other.

+1
Completed

File Filter: support word-part search

Thomas Singer 6 years ago updated 6 years ago 2

Currently, one can filter the Files view by, e.g., "*.txt, *.php". What about searching for file name parts, e.g. "file man" to find SgFileManager.java?

+1

Compare/Changes View: Mark current difference on both sides

arcadius 6 years ago updated by Marc Strapetz 6 years ago 0

Currenly the number of current different line is marked (yellow) only on one (focused) side of Changes window. If user is looking into the code in other side, (s)he will hardly see this mark.

Image 332

It would be handsome if current line's number was somehow marked on the non-focused side too, f.e. with gray.

Image 333

+1
Completed

Commit: option to customize limits of "line length guides"

Andrew Pashkin 6 years ago updated by Thomas Singer 5 years ago 7

In many projects there are guidelines regarding how long lines in commit messages can be. In Linux, for instance, the first line can't be longer than 50 characters. Currently to ensure that I don't break the formatting rule I have to use a dedicated editor with sole purpose of measuring line width and then copy-pasting it to SmartGit "Commit" window. My proposal is to add indicator of current line width into the "Commit" window in SmartGit.