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

With the new Standard window, pull is rejected if working tree contains local changes, error message is:

"The working tree contains local changes.: Commit or stash local changes before pulling."

This behavior is different in log or working tree windows, a pop up allowing to choose some options shows up.

This makes standard window unusable for me.

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.

Depending on whether you're rebasing (Most do) or merging, the conflict resolution dialog ("yours" vs "theirs") can be impossible to determine unless you manually review the commit id in the log.

For those in the team that aren't programmers it is more or less impossible to understand.

The resolution dialog should be expanded to include far more information. At a minimum one could include the full commit message for the conflicting commits.

There seem to exist a couple of different ways to bundle desktop applications on Linux - AppImage, Snap, Flatpak, ... Please vote for the below entries, so we can estimate the distributation.

https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison

When merging a conflict may occur. The repository is now in a merge state, where a user has different options:

• abort the merge
• solve conflicts and continue

While rebase has a "continue" button, merge has non. Users have to know, that the "continue" button is equal to the "commit" button.

The latest version 19.1 RC2 shows a nice bar:

I suggest:

1. Rename "Commit" to "Continue" in that state.
2. Add a continue button close to the "Abort" button in the merging-state bar.

Thanks,

    Patrick

One of the more annoying and complex issues with Git in general is when merging branches or resolving conflicts - Often the dialog of "Use Ours or Use Theirs" or really unhelpful. Not only is it rarely clear what "ours" and "theirs" is, it can often be reversed depending on the merge/rebase/conflict type.

I think SmartGit could really stand out from the crowd if it put a bit more effort into resolving those words into more meaningful ones. Surely it isn't too much work to determine the name of the 2 branches involved? And if it's the same branch, to display the author and date of the 2 commits in question.