SmartGit on macOS 11 (BigSur)

SmartGit 20.2 is the only version which we officially support on macOS 11. There are some known UI-related problems which we are working on.

SmartGit 20.1 is not officially supported on macOS 11. Still, according to user’s feedback and our own experience, SmartGit 20.1 is basically working on macOS 11, however there are a couple of known UI-related problems: some of them are resulting in crashes, others only resulting in UI-glitches. The most pressing of them are already resolved in version 20.2. If you are running into any unexpected problems, please upgrade.

SmartGit 19.1 and earlier are not supported on macOS 11. These versions are known to have several problems on macOS 11. We definitely recommend to upgrade to version 20.2.

SmartGit upgrade on MacOS fails with “Directory ‘…/AppTranslocation/…/’ could not be created”

Depending on how you run/install SmartGit, on upgrade you may run into read-only file system problems which are caused by App Translocation. This happens:

  1. if started directly from the DMG file by double-clicking the; or
  2. if copied from the DMG file to a different location (like Applications) without using Finder, e.g. from terminal by cp -R /Volumes/SmartGit\ 20.1.2/ /Applications

In both cases, in SmartGit’s About dialog, page Information, we can see for Java Version a translocated path containing AppTranslocation.

To resolve case (1), we can simply copy from the DMG file to the preferred location (e.g. “Applications”) using Finder.

In case of (2), from terminal, we can see that the extended attribute “” is set:

$ xattr -l ...;...;Safari;...

We can get rid of this attribute using:

$ xattr -d

Now, when restarting SmartGit, the About dialog will show the actual installation path.

Credits to:

Be sure that core.ignoreCase matches your OS!

When copying repositories back and forth between Windows and Linux/MacOS, you may end up either with core.ignoreCase=false on Windows or core.ignoreCase=true on Linux. Both configurations will usually cause troubles and are not supported by Git [1].

To avoid this, you may unset the core.ignoreCase configuration in your repository root:

$ git config --unset core.ignoreCase

As Git’s internal default is false, there is nothing more to do on Linux/MacOS. On Windows, you have to add core.ignoreCase=true as global default:

$ git config --global core.ignoreCase true


SmartGit 19.1’s auto-stashing of untracked files

A couple of users have complained about changes to the auto-stashing behavior in version 19.1 (compared to 18.2): for various history-related operations (like reordering, squashing of splitting commits), SmartGit 19.1 is now requiring a clean working tree where SmartGit 18.2 did not and also Git command line does not.

In general, SmartGit considers untracked files more important than Git in various places (if not important, why not ignore them?). This is especially true for history-related operations, for which SmartGit is now using Git’s interactive rebase feature. It’s not clear whether all of these operations in combination with the interactive rebase can cope perfectly with untracked files for different scenarios (e.g. Modify/Split Commit). Hence, we require a clean working tree in general.

However there is some problem in SmartGit 19.1’s logic though: SmartGit is not stashing untracked files by default, because certain SmartGit users think that SmartGit must not touch untracked files at all. That’s behavior already present in version 18.2.

Now, combining both, you will run into the problem that SmartGit will ask you to auto-stash before performing a history-related operation, but then will not actually stash the untracked files and hence the operation fails because the working tree is not clean.

A quick solution to the problem is to enable stashing of untracked files in the Preferences, section Commands, Stash. For 19.2 we will try to be more selective here when to require a clean working tree and when not.

SmartGit in Simplified Chinese – thanks to our contributors!

With the release of SmartGit 19.1, big portions of the GUI are now optionally available in Simplified Chinese.

Many thanks to our contributors:

  • Kerwin, for initiating this project and providing and reviewing translations
  • Taotieren, for providing tons of translations

Do you want to contribute, too?

Pull requests with new translations or suggested improvements to existing translations are welcome at:

SmartGit 19.1 is now compatible with Git-Flow AVH 1.12

For SmartGit 19.1, we have changed the internal Git-Flow implementation to be compatible with Git-Flow-AVH (version 1.12.2), as requested in UserEcho topic #409.

This brings new features, like customizable base branches of features, but also (slightly) alters the behavior of existing functionality. Most of these changes can be switched back to the old behavior by adding the appropriate defaults to  your .git/config . For more details, refer to here.


  • Start Hotfix only allows to have a single, active hotfix. To allow multiple hotfixes, add Git config option gitflow.multi-hotfix=true
  • Start Release only allows to have a single, active release. To allow multiple releases, add Git config option gitflow.multi-release=true


Dispelling concerns about SmartGit’s automatic connection setup to your GitHub, Bitbucket or GitLab account

We have been contacted by a user who has concerns about the link setup procedure between SmartGit and Bitbucket (Preferences, Hosting Providers). While the procedure is actually inscrutable on first glance, following it step-by-step we can see that it’s safe with respect to the protection of your Bitbucket account:

As you can see from the Request Access Token dialog, your browser will directly open a Link. If you prefer, you may copy&paste the URL yourself to your browser.

The URL is about OAuth authorization and specifies two parameters client_id and response_type which we can assume. We can assume that client_id is pretty much what it says: the Client ID of SmartGit — otherwise that would be a significant design flaw of the Bitbucket API for such a central end point. We can also assume that Bitbucket is very much interested in telling you exactly for which access rights the OAuth request is asking and that it would warn you about strange requests, to protect its users from malicious applications.

After confirming access, Bitbucket will pass an authorization code to Syntevo’s website. Again, we can assume that whatever this token is, Bitbucket considers it safe to pass on to the requesting application (the detour over is necessary because Bitbucket can’t pass the token directly to your running SmartGit instance).

The authorization token is short-lived and single-use; this especially means that once you have successfully authenticated, you can be sure that the token can’t be used anymore (e.g. by some attacker who could have gained control over the connection between and or over the connection between and your browser).


SmartGit refreshing problems in Parallels VM

One of our OS X users has reported SmartGit refreshing problems when running in a Windows 10 Parallels VM. SmartGit’s low-level Java timers are relying on a “consistent” system time (which will only be advancing). But, as it has turned out, due to clock synchronization issues, this may not be the case for such a setup:

Finally got to the bottom of this! Turns out to be a mismatch in the way that Parallels is emulating the real-time clock (RTC). When you install under bootcamp it sets this registry key to tell Windows that the RTC is in GMT:

Parallels is however incorrectly configured and is emulating the RTC in LOCAL time, not GMT! And for some reason, something in Windows keeps triggering it to correct itself to the RTC while the OS is booted (I can see that in the event logs). Not sure why it does that, but it happens quite regularly during the day. Since the RTC is not correct, it puts the system to LOCAL – 8 hours, (GMT – 16), and if I have the Parallels time sync service active it quickly notices and corrects it.

One way to work-around this problem is to disable the time sync service:

I have the Parallels time sync service off at the moment and have told Windows to expect the RTC to be in LOCAL time, and now it is all working nicely.

I have also been on calls with Parallels second level support who is talking to their engineers and they hopefully can make it work correctly in a patch release of Parallels, because if I boot my Mac into bootcamp natively right now the time will be off because Windows will think the RTC is LOCAL time, while in fact the Mac always has it set to GMT.