SmartGit should be able to handle multiple diff tools for the same file type. The Diff tool with the highest ranking should be available for the standard diff command just as it is now. All other matches should be available in a context-menu submenu.

Reasoning: There are many diff tools that support multiple modes (e.g. beyond compare can do hex-compare as well as text-diff). Files may contain plain-text headers but binary payload. Also, each tool might have strengths and weaknesses.

By allowing an easy way to choose another tool, the user can easily select the tool best suited for the task at hand.

This would also allow users to have a custom "show this file in explorer" command (see https://smartgit.userecho.com/topics/180-log-files-list-please-add-open-and-reveal-in-explorer-in-context-menu/) without sacrificing the ability to do diffs

Optionally provide Log filtering using some sort of query language. For example:

+author:tsinger +branch:smartgit-8 +message(performance)

-message(log)

to search for all commits by tsinger on

branch smartgit-8 containing the term "performance" but not containing the term "log"

In the "files" pane, we have a search field like this:

It would be great to have the same thing in the "Repositories" pane. I have 1,300 projects in SmartGit, and it since many of the repos are organized into groups, it gets unbearably hard to find a repository sometimes.

SmartGit replaces spaces with underscores when creating a branch name, but not when creating a tag name, remote name, etc. It should just automatically replace in all those fields that don't accept spaces

In some of our repositories we have commits from developers with different Name, but with same email address (short name, full name).

git already supports user name mapping by using a "mailmap" file, so only one name will be display in e.g. the git short log. SmartGit should support this, too.

On GitHub you can assign one or more person to review your pull request. So it would be great to have the same in smartgit. The only thing why I can't use only SmartGit for PRs.

Currently changes in a submodule which is configured with ignore = dirty is shown in Smartgit (7.1.4 #6127, installed: #6097) but not in the command line version of git. Smartgit should respect the ignore = dirty flag and not show these changes.

For instance the following .gitmodules causes the git bash command to ignore any untracked file inside lib/common-libs, but SmartGit still shows the untracked files:

[submodule "lib/common-libs"]
        path = lib/common-libs
        url = git@10.1.2.165:EMS/common-libs.git
        ignore = untracked

Everytime I have a conflict in git and I need to resolve it by choosing "Take Ours" or "Take Theirs" - I get confused
I roughly remember that if I do merge - Ours is mine, Theirs is remote

If it's rebase - it's reverse... when applying stash - it's something else...

So thinking about this is hard.. and I am never sure I got it correctly
What I do in the end - I right click file, go to commit log... look at commits and then select file and "Save as after" and Stage to resolve the conflict so I really know which commit is "ours" and which commit is "theirs"

My suggestion is:

everywhere where in UI you write "Take Ours" and "Take Theirs" - do add more info i.e.

Take Ours (<hash> <branch> <author> <message>)
Take Theirs (<hash> <branch> <author> <message>)

It's especially helpful with non tech people (like artists)
Explaining to them insanity about "ours" and "theirs" is pretty much impossible

GitLab uses git "push options" to allow CI to be skipped for a specific push. We push the same commit to multiple branches and use the git push option when we don't want CI to be run. Putting a CI skip in our commit message would not work because we want CI to run for some of our pushes, and because with our use cases, CI skip would not make sense to have stay in our commit history.

The ability to check a box when I am doing a push to specify that I want to skip CI for that push would be awesome.

I don't care about any other git push options right now, but it might be worth considering that people might come up with new & useful ways to use git push options over time.