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

The new icons in SmartGit 26 for "untracked" and "added" states are very similar in color and shape, which makes it hard to distinguish between those states. This is especially an issue in the working tree view, where both icons are mixed.

It would be better if the untracked icon had a different color than green (it previously was blue in SmartGit 25), since this would help to see the state at once without paying attention to the exact shade of green or the additional white pixels between the star and plus icon. 

Hello,

Could an option be added to include the --update-refs arguement for rebase operations? Either in drop down menu during rebase or just a checkbox in preferences / advanced settings would be fine from my perspective.

I quite often work on large features that then get split into multiple branches stacked on top of each other.

I generally work on projects using a rebase strategy rather than merging branches into main, so I end up wanting to rebase the stacked branches onto the head of main for testing / submission.

Currently I end up needing to drag/drop the whole branch onto main to rebase it as just the lastest branch name, then manually drag the intermediate branch labels up to where they're supposed to be in the stack which is quite tedious and error prone. 

Alternatively I drop to the terminal to run the rebase there with --update-refs and it moves all the intermediate branches for me along with the rebase.

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.

Note: if you are just interested in filtering the Log graph for a specific sub-directory, see topic 879.

As in the working tree window, in the Log it should be possible to invoke commands on directories, too:

• working tree commands (like staging all files in a directory)
• external tools (like opening the terminal for a directory)
• sub-directory logs
• .... what else do you need?

Please post your ideas on how such an integration should look like!

Note, due to several usability and technical reasons, we won't add directories to the Repositories view.

Sometimes I'd like to search the (all, not just the modified ones) files of the commit currently selected in the Log window. This may be useful if a method does not existing any more but you know a state where it existed.