For a fresh new SmartGit install in my team, we always need to change the default pull behavior : doing a rebase with local changes instead of a merge commit. The later produces absolutely unreadable logs and I think for the vast majority of users is an aberration.

So I'd suggest to change the default value, or make it configurable as soon as clogin / opening a new repo.

SmartGit should support git-repo. https://code.google.com/p/git-repo/

This is a multiple repository management tool built by google used by several large fortune 500 companies. It provides a easy way to sync a large number of repos (over 100 or more) to a specified commit tag that is specified in a manifest file, which is in it's own repo. This is how we are managing our software build where each project can contain hundreds of repos.

It's already in the "Show Changes" option, but you should add a setting to use that editor when you double click on a file in the files tab.

Currently the new repository is appended to the bottom of the list, it would be nice if it's added to the currently selected repository group instead (or add the "repository group" select box to the "Add repository..." dialog and make the currently selected group the default option). It's tedious to have to scroll and drag the new repo through the long list.

However, "after" executing a command from SmartGit is showed in the Output window but showing the respective git command will make CLI users easily aware of the commands provided by SmartGit "before" actually executing; and newbies can also learn commands.

Similar to Sublime Text, Atom and gitkraken I would love to see two menus:

Ctrl + P: fuzzy search files in a repo and execute commands on the file (blame, log, etc.)

Ctrl + Shift + P: access (git) command palette (basically all commands known to git)

Both commands are global (in terms of focused window) and bound to the currently selected repository.

The theme option "automatically select light/dark" is really nice to adopt to operating system theme settings. However, it is usually the case these days that e.g. macOS changes dark/light automatically during the day depending on daylight etc. At this point almost all other applications dynamically make the switch while using them, but SmartGit needs to be restarted each time the theme changes. This means you have to restart at least once or sometimes twice every day.

It would be really nice if the light/dark switch happened truly dynamically, not requiring a restart.

Hello, I could not help but notice that Smartgit is A) a Java-based app and on mac, you bundle JRE.

and B) the Smartgit on apple Mac m1 arm chips runs via Rosetta2 Intel emulation.

I have managed to make the app quite usable by using manually installed Git executable via homebrew, but I noticed that Zulu has compiled and released both Java 11 LTS version and latest java 15 version for mac M1 arm which runs natively and is quite good and quite fast.

I have looked into overriding the java version used in smartgit but do not wish to mess about too much.

Do you think perchance you could release your next mac dmg with a native arm JRE or the ability to override the JRE?. 

Think it would be WAYY better if smartgit worked natively on the latest mac platforms. (perhaps have an alternative arch dmg download)

Perhaps my use-case is pretty specific, but I have multiple GitHub accounts that I use for very different purposes. Because both accounts have private repositories, if I want to switch between the two accounts, I need to go into preferences, remove the current GitHub account, add the new account (generating a new OAuth token) and then continue making commits etc.

It would be very convenient to be able to have multiple accounts with the OAuth tokens / credentials saved, so that I could quickly switch between them. They don't need to both be active simultaneously. Ideally they could also be associated with specific repositories, so that if I open repo A, SmartGit automatically switches over to GitHub account A, and if I switch to repo B, SmartGit switches over to the corresponding GitHub account B.

I'm not sure how many other people need this sort of thing, but it would help me out a bunch, and I imagine it wouldn't be super complicated to implement...

- Have a branch named A

- Push it to origin

- It starts tracking origin/A

- Rename the local one to B

- Delete the remote origin/A

- Push the local B to origin

It gets pushed to origin/A.