Some editors, including Sublime Text and Vim, allow to specify the line number on the command line.

Examples:

subl myfile.txt:123

vim myfile.txt +123

If started this way, the editor opens myfile.txt and moves the cursor to line 123. This is very convenient if the editor is launched using a shortcut from another tool, e.g. from a debugger - the cursor is places exactly on the line that requires user attention.

Now it would be convenient if SmartGit allowed to traverse the changes in the Working Tree (in the right page) using the F6 key and then, if manual intervention is needed, to start an editor with the cursor placed on the same line that it is placed in the Working Tree view.

To achieve this, please consider adding a ${line} (or ${lineNo}) variable to the variable list

in the Edit External Tool dialog (as seen in the screenshot).

edit-external-tool.png

Thank you and good luck,

Peter

I tend to run with only some repositories open but when I want to open another repository alongside them I have to select my currently open ones alongside the new one to keep them open. It would be great if there was a context option (or preference where it didn't close repositories when opening a new one.

SmartGit 20.1 already denotes signed tags and commits (in the Branches view and Log graph) by black key symbols.

SmartGit should also verify these signatures (if possible) and denote:

- signature OK
- signature could not be verified (bad?)
- signature unknow

SG displays and requires clicking "Force Compare" for a text file that git by default says is binary due to first line length is long, even though .gitattributes defines it as text. 

Since .gitattributes has the file defined as text, SG should automatically diff it.

Most times when I am editing a file in the File Compare window, I jump to my text editor/IDE because I need advanced tools.

But when I come back to the File Compare window, my changes are not reloaded on the right pane:

Then, I have to copy and paste the entire buffer.

It would be a nice option if Smartgit detected the file on the right had changed, and then ask to reload it.

The gitlab integration is great, but when doing a "merge merge request", the merge request is immediately merged. It would be great to have the option to use GitLab's "merge when pipeline succeeds".

Git itself does not have "remote tags" as an explicit concept but one can workaround it by introducing custom refs, like 'rtags'. This basically requires to add an additional fetch-refspec like:

[remote "origin"]
  ...
  fetch = +refs/tags/*:refs/rtags/origin/*

This makes Git always reflect and update the server-side state of tags on pulls and pushes.

Now, SmartGit could interpret this special "rtags" refs and apply the same logic to it as it does for remote and local branches:

- evaluate ahead/behind/diverged state for tags

- in the Log, have puzzle-piece display of tags

- forced-push checks for tags

- ...

SmartGit does not Support includeIf.path introduced with Git v2.13 (released May 2017) and it’s ruining my workflow between my personal and work projects (I use the same laptop).

Using:

[include]
path = ~/.gitconfig-personal

Works just fine, but using:

[includeIf "gitdir/i:~/Workspace/**"]
path = ~/.gitconfig-personal

Does not work at all…

The .gitconfig-personal file includes my e-mail address and when I use SmartGit, since that file is not included when working with a repository inside ~/Workspace/, SmartGit complains of missing e-mail address.

This is a problem with SmartGit because although SmartGit complains about the missing e-mail address, I can still commit and my e-mail address will be added successfully to the commit by git.exe (because git.exe reads the includeIf directive properly, while SmartGit does not).

Also, please take into consideration that if you have a configuration like this:

.gitconfig

[user]
name = Ricardo Amaral
email = name@personal.com

[includeIf "gitdir/i:~/Workspace/Work/**"]
path = ~/.gitconfig-work

.gitconfig-work

[user]
email = name@work.com

The e-mail being used by Git for any folder outside of ~/Workspace/Work/ will be name@personal.com but any Git repository inside ~/Workspace/Work/ will use name@work.com. In other words, after parsing the full Git configuration (taking into consideration "include" and "includeIf" directives), the parameters that precedence (if found duplicates) are the ones on the bottom of the

In the Log Window, if I right-click on a commit and added a branch, one would expect that the newly-added branch to appear in the graph.  However, if the current setting is "Show Selected Refs", the branch is not shown because the new branch in unchecked by default.

I strongly believe that new branches should be checked by default, and appear immediately on the graph, regardless of the "Show Selected Refs" setting.  The locality of the action (or context) outweighs the setting -- it left me wondering whether I did create the branch successfully or not.