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.
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:
- if started directly from the DMG file by double-clicking the SmartGit.app; or
- 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/SmartGit.app /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 SmartGit.app 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 “com.apple.quarantine” is set:
$ xattr -l SmartGit.app
We can get rid of this attribute using:
$ xattr -d com.apple.quarantine SmartGit.app
Now, when restarting SmartGit, the About dialog will show the actual installation path.
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 .
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
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.
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:
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
- Start Release only allows to have a single, active release. To allow multiple releases, add Git config option
We have started with the internationalization/language localization of SmartGit (UserEcho topic 76). The first language we are working on is Simplified Chinese. If you are a native Chinese speaker, your contributions would be much appreciated. For details on how to contribute, please have a look at the Internationalization How-To.
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 bitbucket.org 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 syntevo.com 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 bitbucket.org and syntevo.com or over the connection between syntevo.com and your browser).
This SmartGit preview version comes with more Log improvements and bug fixes.
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.