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:
https://lapcatsoftware.com/articles/app-translocation.html
https://apple.stackexchange.com/questions/87313

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:

https://github.com/syntevo/smartgit-translations

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.

Examples:

  • 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