Let's take a look at the Changes -> Settings dialog. It only effects the belonging view unless you select the "Remember as default" option. This you would lose if you would only have one preferences option.

The Repository | Settings and Remote | Properties dialogs work on the selected repository or remote. Making them available in the Preferences dialog would be very bad UX because the preferences never work on any selection.

I'd rather tend to do the opposite and spread the options to the places where they actually act. One example are the new options in the Branches and Journal views in the 3-lines-popups. I'm sure, this is easier to discover. Options that act on multiple places, I'd try to keep in the preferences.

Currently, we use VM properties for options that should not be exposed to the GUI and because it is easy to implement (calling something like System.getProperty(key, defaultValue)). If this would become harder to implement, we would implement fewer options and hence need to reject some configuration requests.

I assumed you mean to replace one global ~/.gitconfig for your private repositories with another one for your company's repositories. Maybe this was a wrong assumption? What exact options do you want to be switched between private and company profiles - name, e-mail or also additional stuff?

How do you think this should be implemented? Should SmartGit really write ~/.gitconfig before each command execution?

You can select what ${commit} actually should be allowed - could be ref or SHA.

SmartGit 17.1 offers batch-mode interactive rebase. Our existing Journal functionality uses cherry-picks because Git's rebase is dog-slow on Windows.

The focused control should be easily visible from the view's tab color.

This would be a very bad user experience. A selection change never must cause a dialog to occur. I also consider a dialog on a focus change as bad user experience.