We are frequently contacted by users which are wondering why certain Git operations in the Files view are not available or why certain toolbar buttons are grayed out. Usually, it turns out that this is caused by having the HEAD commit selected instead of the invisible working tree node: if the working tree is unmodified, it will be hidden by default and thus to have all operations available it must first be revealed using the Graph’s Home button (house symbol).
There is already the Show Working Tree Permanently option in the Graph’s options menu, but it’s not the default and thus the vast majority of users don’t recognize it.
Our proposed solution to this problem is to make Show Working Tree Permanently the default. This will make the working tree functionality in the Log more obvious and easier to invoke. Users which prefer to not see the unmodified working tree can simply toggle the option off.
SmartGit’s SVN integration will be discontinued on Dec 31, 2022. We have decided to take this step because the amount of users of the SVN integration is steadily decreasing and is already less than 1% of overall Git users. On the other hand, the SVN integration affects many code parts, making them harder to maintain/change. Also, the support effort for non-default SVN server layouts is quite high. When putting increased maintenance effort into relation to the low number of users, we believe that dropping the SVN integration will be beneficial for our overall user base.
What does that mean for you?
If you are not accessing SVN repositories, this will not affect you at all. Note that former SVN repositories which have been converted to Git once and since then are only used as Git repositories (i.e. no more pulling/pushing back to SVN) are actually pure Git repositories and thus will not be affected.
If you are actually still accessing SVN repositories, you can continue using the latest major version released before Dec 31, 2022 even after this date (of course, only on the operating systems supported by these versions) to clone/push/pull to your SVN repositories. There will be no more bug-fixes to the SVN integration for these versions after Dec 31, 2022, though.
For major versions released after Dec 31, 2022 the pure Git functionality will continue working with already cloned SVN repositories, but pulling/pushing (or cloning new repositories) to/from SVN servers will not be possible anymore.
We recommend to convert your SVN repositories to Git or use SmartSVN to access them.
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).