Log4J vulnerability “Log4Shell”: our recent product versions are not affected

The good news: none of our recent product versions is using Log4J:

  • SmartGit 18.1 and newer
  • SmartSVN 9.3 and newer
  • SmartSynchronize 3.5 and newer
  • DeepGit 4.0 and newer

However, Log4J 1.x was used by older versions of our products:

  • SmartGit 17.1 and older
  • SmartSVN 9.2 and older
  • SmartSynchronize 3.4 and older
  • DeepGit 3.0 and older
  • SmartCVS

Log4J 1.x should not be affected by CVE-2021-44228 (“Log4JShell”), but there is another important vulnerability CVE-2019-17571 affecting Log4J 1.x. For this reason, we have decided to remove the affected versions from our download archive.

SmartGit: the new Standard window

For version 22.1 (currently in development), we have introduced a new main window in addition to the existing Log and Working tree window: we call it the Standard window because it enforces some standards on the way Git is used.

SmartGit is known to be a very powerful and flexible client when it comes to Git functionality. This is especially great for power users, but it may be overwhelming to less experienced Git users. With the Standard window we are closing this gap by channeling Git functionality into workflows, to avoid potential pitfalls.

Mode-adjusting GUI layout

The most important difference compared to the existing Log and Working tree windows is a GUI layout with different modes for Local Changes, My History, All Tags + Branches and Stashes. Every mode serves a specific purpose and is optimized for certain workflows and repository states:

  • the visible Git information is restricted to what is required by the workflows
  • the toolbar offers the most important operations, guiding the user through the workflows

More specifically,

  • the Local Changes mode serves for committing, resolving conflicts, searching or modifying local files in the Working Tree and Index
  • the My History mode shows your local branches and will be sufficient for 95% of the daily commit-related tasks
  • the All Branches + Tags mode gives an overview of all branches and tags and can be used for checking out non-local branches or merging/cherry-picking from these branches
  • the Stashes mode allows to inspect the content of stashes and to apply or drop them
  • the GUI automatically switches between Local Changes and My History, as appropriate for the current workflow

Optimized for common workflows

Another important principle of the Standard window is to make common workflows easier, at the expense of making uncommon workflows harder:

  • several operations have less options and sometimes do not even require a dialog anymore (e.g. Push, Pull)
  • some operations are more restrictive, e.g., require a clean working copy
  • inspired by Git-Flow, we have implemented a robust feature branch life-cycle: Start, Integrate, Finish

Clean GUI

The mode-adjusting layout allows to give sufficient space for the relevant information. This eliminates the need to permanently resize views. On top of that, the GUI has been further simplified and cleaned up:

  • one tab per repository
  • clear separation of Working Tree vs. Index vs. Commit graph
  • sets of independent orthogonal GUI operations have been compressed into simple lists of excluding configurations (for example, show Changed files vs. All files)

Give the Standard window a try

To give the Standard window a try, get SmartGit 22.1 Preview from:


You need to have a commercial license registered.

Tuning rebase performance on Windows

One of our Windows users has reported that rebasing a large feature branch takes significantly longer with recent SmartGit versions.

SmartGit comes with its own Git bundled which we are usually updating for every major SmartGit release. As it turns out, since Git version 2.26, the rebase backend has been switched from “apply” to “merge” which is in general superior, but which seems to run slower on Windows, at least for specific scenarios (we couldn’t identify any significant slowdown on Linux).

To improve rebase performance to pre-Git 2.26, you can switch back to the old “apply” backend. To better understand whether this is a viable solution for you, first make sure that the subtle differences between both backends will be acceptable. If so, you may configure per-repository:

$ git config rebase.backend apply

or globally:

$ git config --global rebase.backend apply

Twitter Poll: should the Log by default always show the working tree node (it will still be easy to switch off)?

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.

Poll: https://twitter.com/smartgithg/status/1370385647719084040

SmartGit SVN integration: end-of-life announcement

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 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/…/SmartGit.new.app’ 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 SmartGit.app; 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/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
com.apple.quarantine: ...;...;Safari;...

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.

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

[1] https://git-scm.com/docs/git-config#Documentation/git-config.txt-coreignoreCase

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: