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


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.

Controlling SmartGit using an eye tracker

While eye trackers are not (yet) common computer peripherals, they have some fascinating potential to change the way we could be interacting with computers. I’ve done some experiments with the Tobii Eye Tracker 4C, a low-priced consumer device, to see whether/how it might improve SmartGit’s usability. The device is not pixel-precise, hence the interaction has to be restricted to larger areas of SmartGit’s user interface. The four screencasts below include the “gaze trace” and give some ideas of how eye tracking based interaction could look like:

Expanding/enlarging focused views, like the Journal

Adding details to focused (groups of) UI elements

Note that at least for my eyes, the precision was not sufficient to determine a single focused row in the tree, but only a bunch of 3-5 rows.

Scrolling the Commits graph by gazing to the top/bottom of the graph

Activating a (hidden) tab

SmartSVN OpenAPI deprecated

For upcoming SmartSVN version 9, we are going to deprecate the OpenAPI. For the next major version (after release 9), the OpenAPI may be removed entirely. The functionality of all bundled plugins (e.g. the JIRA plugin) will be preserved.

Why we ask non-commercial users to run a recent SmartGit version

Non-commercial users sometimes complain about warnings and final deactivation of older SmartGit versions. Now why are we doing this?

First of all, we’d love to see everybody running the latest version of SmartGit, regardless whether commercial or non-commercial user. We are steadily improving SmartGit and only supporting (fixing bugs in) the latest release version. Hence we are confident that the latest version contains the best features and is most stable.

Commercial users get between 1 and 3 years of updates. That means they can use any major new version which we release up to 3 years after the purchase date (including all bug-fix release, even if released later). If they want to use newer versions, they have to purchase update licenses.

Non-commercial users get SmartGit free of charge. The upgrade to a new major version is as easy as a download and will become even more convenient with upcoming versions. Hence, costs are only a few minutes of time vs. gain are new features and improvements in other areas.

Our gain of having non-commercial users running the latest version is a faster spreading of new versions, resulting in better reviews and less problem reports.

SmartSVN: missing/unversioned file pairs on OS X

We are frequently getting bug reports of “normal” files showing up as a missing/unversioned file pairs on OS X. This happens if they contain non-ASCII characters (like German Umlauts) in their names and they have been added from another platform, like Windows or Linux or directly from the Repository Browser.

Known Subversion problem

This is a known problem of Subversion: in short, Subversion stores file names “as is”. When adding a file “schön” on Windows, its name is stored in this “composed” form in the repository. When checking out the file on OS X, the filename is converted to “decomposed” form when writing to the file system, resulting in “scho¨n“. Thus, svn status will see a different file in the working copy than in the repository and hence report the missing/unversioned file pair. Further details can be found at Subversion issue #2464 and in the Subversion Wiki.


Unfortunately, it’s currently not clear whether this problem will be solved for Subversion/when the fix will be present. The only known workaround is to get rid of such special characters in the repository completely:

  • in case there are only a few files, you may use the Repository Browser to Rename the offending files, then update your working copy
  • in case there are many files affected, it will be better to check out a fresh working copy on Windows or Linux, rename all offending files in the working copy and finally commit all these renames at once