Frequently Asked Questions
Tower runs on Intel-based Macs with OS X v10.8+. An installation of Git is not required since Tower comes with a fully functional Git binary.
Be careful with third-party "Unarchiver" / "Unzip" applications. E.g., the "Unarchiver.app" has a known issue on Mac OS 10.9+ that can corrupt ZIP contents. Please use the standard OS X tool to unzip the downloaded archive and you'll find that the Tower.app is properly code-signed.
Please have a look at our release notes.
In some rare cases, the updater cannot properly quit the "old" Tower app as you hit the "Install and Relaunch" button of the updater. This will prevent the new Tower version from starting up, showing just the main menu, but no window.
In this case, you need to quit the old Tower process yourself by starting the OS X "Activity Monitor" application, search for "Tower" and quit all processes that show up selecting "Quit Process" from the toolbar. A reboot of your machine will also work.
After terminating the old process, Tower should start up normally again.
Releases in the stable release channel are delivered via:
Releases in the beta release channel are delivered via:
On our support page, you can enter the email address used to place your order and have your license key resent.
If you want to be the first to have new features and fixes, you can have early access to "Beta" versions of Tower. Simply do the following:
- open Tower's preferences on the "Updates" channel
- configure "Beta" as your release channel
- restart Tower
- choose "Check for Updates..." from the main "Tower" menu
From now on, you should always get our latest beta versions!
When Tower crashes (i.e. is unexpectedly terminated), please send us the corresponding crash report. Be sure not to confuse Tower's crash reporter with Apple's own crash reporting interface.
In contrast, when Tower hangs or has a high CPU usage, you can help us identify the problem by opening ActivityMonitor.app.
Select Tower in the list of running applications, then "Sample Process" from the action menu.
This will open a new window, creating the sample.
When it has finished creating the sample, please save the report by clicking the “Save…” button in the upper right corner and attach the file when sending us the bug report.
We've prepared a "Troubleshooting Guide" that walks you through the most common pitfalls with remote connections.
Yes, hook scripts are respected by Tower. However, there are a few things to consider:
When you run Git from the command line, it runs in the environment as set up by your Shell. GUI OS X apps, however, have no knowledge about your shell - and the PATH environment can be changed in many different places. The actual environment they run in even varies depending on how the application has been started:
- From Spotlight
- From Finder
- From the Dock
- From the Terminal with the open command (or our CLI Tool)
The important question is: Do your hook scripts rely on the existence (or on specific values) of shell environment variables that are created/modified in your shell profile (like extending "PATH" by a non-standard-path (e.g. '~/bin')?
In that case, you have two possible ways to set up your required environment:
- Set it up in the hook script itself. Please keep in mind things like modifying "PATH" should not be done in your shell profile, as the hook script is called from the Tower process environment which is not running in a shell environment (hence your shell profile is not loaded).
- Set it up globally in Tower by using our environment.plist.
Also note that if your hook script prints out error messages and you would like them to be displayed in Tower, you have to make sure the error message is printed to STDERR:
echo "Error!" >&2
Interactive scripts that require user input as part of the script are currently not supported in Tower.
The photos come from gravatar.com. If you (or the committers in your project) have an account at gravatar, Tower gets the image for this account (account identifier is the email address).
An important thing to note is that the email of your Gravatar account must be the same as the email that the committer / author of the corresponding commit has.
So, if you committed with your git config email address set to "firstname.lastname@example.org" and your gravatar account has the same email address, then you should definitely see your picture.
When writing commit messages, you can have OS X mark & correct spelling mistakes. To configure this, make sure the "Commit Subject" textfield is focused and choose your setting in the "Spelling and Grammar" submenu in the "Edit" main menu.
Tower enhances the sidebar with elements like custom badges etc. While this works in Mac OS 10.8, it causes rendering glitches in version 10.9+. This is a know issue in Mac OS X that we've already reported to Apple.
When Git creates and stores a commit, the commit message entered by the user is stored as binary data and there is no conversion between encodings. The encoding of your commit message is determined by the client you are using to compose the commit message.
However, Git stores the name of the commit encoding if the config key "i18n.commitEncoding" is set (and if it's not the default value "utf-8"). You can print its current value with the following command:
$ git config i18n.commitEncoding
If it shows no output, it defaults to "utf-8".
If you commit changes from the command line, this value must match the encoding set in your shell environment. Otherwise, a wrong encoding is stored with the commit and can result in garbled output when viewing the commit history.
Tower uses and enforces UTF-8 as encoding for commits (regardless of what is set for "i18n.commitEncoding") to ensure a valid commit encoding.
On the command line, you can verify your encoding with the following command:
$ locale LANG="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_ALL="en_US.UTF-8"
This prints your current character encoding settings. Additionally, when using Terminal.app on OS X, you should make sure that your preferred encoding is correctly set in the preferences as well.
You can set your preferred shell encoding with the following lines in your shell profile:
export LANG="en_US.UTF-8" export LC_ALL="en_US.UTF-8"
Note: You should rather adjust your shell environment to UTF-8 than your Git config - because UTF-8 is the recommended encoding.
Viewing Commit History and Encodings
If you view the commit log on the command line, the config value "i18n.logOutputEncoding" (which defaults to "i18n.commitEncoding") needs to match your shell encoding as well. The command converts messages from the commit encoding to the output encoding. If your shell encoding does not match the output encoding, you will again receive garbled output!
However, if the commit message is stored with the wrong encoding and viewed with the wrong encoding, the commit message will display correctly. While this may look fine on your system, as soon as you share the commits with someone else, she will receive garbled output.
Inspecting Commit Encodings
Once a commit has a wrong encoding, there is no reliable way to detect and fix the encoding when the commit is displayed by clients. If possible, try to recreate the commit with the correct encoding by rebasing it.
If you want to examine a commit and its stored encoding, you can use the following command to inspect it:
$ git log -1 --pretty='format:%h: "%B" (Encoding: "%e")' SHA
You can also override the config value for "i18n.logOutputEncoding" when invoking the command to convert the encoding to the given output:
$ git -c i18n.logOutputEncoding=UTF-8 log -1 --pretty='format:%h: "%B" (Encoding: "%e")' SHA
In recent versions of Mac OS, a new setting controls if applications should re-open windows. In your Mac OS System Settings, in the "General" section, make sure the option "Close windows when quitting an application" is not set if you want Tower to open the windows that were open before you quit it.
Using unicode filenames (e.g. like the German umlaut "Ü") in Git can cause problems - unless the correct configuration is used before working with the repository.
Certain characters can be represented in two different forms in Unicode, for example,
Ücan be represented as the single character
Ü(known as “precomposed form” or
NFC) or as two characters
¨(known as “decomposed form” or
NFD). Both are valid representations of the same string.
You can read more about this topic on Wikipedia – Unicode equivalence.
Depending on the operating system and file system, unicode file names might get converted to either form. Mac OS X (with HFS+) decomposes file names before storing them (thus using NFD), whereas Linux and Windows usually use NFC.
The Git config setting
core.precomposeunicodeconverts between NFD filenames on Mac OS X and NFC filenames in Git:
core.precomposeunicode This option is only used by Mac OS implementation of Git. When core.precomposeunicode=true, Git reverts the unicode decomposition of filenames done by Mac OS. This is useful when sharing a repository between Mac OS and Linux or Windows. (Git for Windows 1.7.10 or higher is needed, or Git under cygwin 1.7). When false, file names are handled fully transparent by Git, which is backward compatible with older versions of Git.
The default for this config setting on OS X is
trueand there should be no reason to override it. Note that the setting is also important when sharing repos between Macs.
The descripton does not go into great detail, but the setting affects various Git commands, most importantly
git add– if
falsewhen a unicode file name is added to Git on OS X, Git registers the decomposed file name. This leads to the following problems:
- Users on Mac OS X with
truewill see the file as untracked in Git status
- Users on Linux or Windows will see the file as untracked in Git status (as
core.precomposeunicodeis not used on those platforms)
This can easily be reproduced with the following test repository on Mac OS X:
git init . touch decomposed-filename-with-ü git -c core.precomposeunicode=false add decomposed-* git commit -m "Add file with decomposed filename on Mac OS X (core.precomposeunicode=false)" touch precomposed-filename-with-ü git -c core.precomposeunicode=true add precomposed-* git commit -m "Add file with precomposed filename on Mac OS X (core.precomposeunicode=true)" git -c core.precomposeunicode=false status --porcelain => ?? precomposed-filename-with-ü git -c core.precomposeunicode=true status --porcelain => ?? decomposed-filename-with-ü
Once a file name has been added in decomposed form to a Git repository, the only way of solving the problem is to remove these files from Git and re-add them with
trueon Mac OS X or perform this action on Linux or Windows.
To recap, if you have problems with unicode file names showing up as untracked:
core.precomposeunicodeis globally set to
trueon OS X
$ git config --global core.precomposeunicode => true
- All files still shown as untracked need to be removed from and re-added to Git.
- Users on Mac OS X with
Tower comes with support for many Diff and Merge tools. If you have problems using a certain tool with Tower, please see our detailed help page on Diff & Merge Tools.
You can use Tower with any Git repository - no matter where a possible remote repository is hosted.
In addition, Tower offers close integrations with the following hosting services:
Each repository on github.com has a "Clone in Desktop" button in the right sidebar. You can use this button to have the repository cloned in Tower - after following these instructions:
- In Tower's Preferences, on the "Integration" tab, make sure that you have "Open repositories from github.com" set to the Tower app
- To make those links appear at all in your browser, you have two options:
(a) Either download & install the GitHub for Mac app and sign in with your GitHub account (in the app's Preferences dialog).
(b) Alternatively, you can install a free browser extension that provides the "Clone in Desktop" links: github.com/gdelmas/GithubTower
In April 2015, GitHub presented a new feature called Git Large File Storage (git-lfs).
git-lfs comes as a Git extension, an additional command that is simply copied alongside an existing Git installation. Because of this, it works seamlessly with Tower. However, you need to select the Git installation in the Tower preferences where you have installed git-lfs.
By default, git-lfs will be installed in
/usr/local/bin, when using the manual installation or when using Homebrew. Therefore, you need to have an existing Git installation in
/usr/local/binand then select this Git installation in Tower. Otherwise there will be a Git error stating that the
git-lfscommand could not be found.
The following plugins for Tower are available for free:
Command Line Tool
The CLI tool that is shipped with Tower allows you to launch Tower right from your command line. To install it, open Tower's preferences on the "Integration" tab.
Using Tower's custom URL handling is an interesting way to open the app right from your browser. Tower will react on its custom URL scheme "gittower://openRepo/" + a remote repository URL
When using Tower on OS X 10.8 with Subversion Repositories (git-svn), the following error can occur:
Can't locate SVN/Core.pm in @INC (@INC contains: [...]
Since version 10.8, Mac OS X does not include certain PERL Subversion libraries anymore which are required by the git-svn installation bundled with Tower.
The only solution at the moment is as follows:
- Download and install the latest Xcode command line tools from Apple: developer.apple.com/downloads
- Change the Git binary used by Tower. You can do so by opening Tower's preferences on the "Git Config" tab. There, you should configure to use the system binary ( /usr/bin/git).
With git-svn, we don't have any chance to accept the certificate in Tower because git-svn doesn't provide any parameters for this. You will have to accept the certificate permanently (by pressing "p") when cloning via the command line.
After having cloned the repo on the command line you can perfectly go on working with it in Tower - simply by adding it to Tower via "Add Existing Repo" like any other existing local repository.
It's important not to have a Git remote and a git-svn remote with the same name. If both Git and git-svn have the same remote name, the remote branches of the remotes will overwrite each other; and there will probably be other side effects, too.
git-svn remotes do not show up in “git remote -v”, as their config is different:
[svn-remote "svn"] url = https://host/svnrepo fetch = trunk:refs/remotes/svn/trunk branches = branches/*:refs/remotes/svn/* tags = tags/*:refs/remotes/svn/tags/* [remote "origin"] url = https://host/gitrepo.git fetch = +refs/heads/*:refs/remotes/origin/*
Tower, however, displays git-svn remotes as normal remotes.
If you need to have both a Git and a svn-remote, you should clone the svn remote with “--prefix=svn/”.
For some reason, the git-svn team chose “origin” to be the default prefix name; this can be problematic as you cannot have a Git remote with name “svn” nor “origin” as they would collide. If you use the prefix with “svn/”, you can then add your Git remote as “origin”.