nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Sourcetree generally slow?

Broes Cat

On testing the beta release 0.9.4 of sourcetree, it turns out to perform unusably slow on basic operations like staging changes or opening commits.

Is this a known issue, or are there certain settings that might affect this?

The issue is not because of git itself, as command line git and the git extensions gui both work like a charm (sourcetree does provide more features).

Project size is 100s of files and 1000s of commits.

Accepted answers

All comments

Broes Cat

Platform is Windows 8.

stevestreeting

I use SourceTree as my own primary Git tool on Windows and don't find it slow on these actions, so I'd be interested to know more about the circumstances. Is it always slow, and what do you define as 'slow'? How large is the repository (both from the root and just the .git part)?

Broes Cat

Repo size is 111Mb, .git is 55Mb (recent clone).

The actions are not always slow and maybe not extremely slow, but combined with the fact that the "progress bar" is shown for almost all actions, it feels "busy" very often. E.g. staging files one-by-one takes a second or 2 per file in which nothing can be done. Refreshing the history view can take more than 10 seconds.

Johannes Kilian_pi36cl

Is your repository on a local drive or is it on some kind of network drive?

Broes Cat

Fully local.

Andy Charalambo

I am experiencing this too - Windows 7.

I also use SourceTree on OS X Mountain Lion and on this system it's zippy as anything and very productive. On windows it's at the point where I think I will ditch it and try something else or go back to the command line.

KieranA

Hi Andy,

I can confirm some major speed improvements have been made for the next release, more than twofold in fact. This should be released next week (I'm guessing it'll be 1.0.5).

Cheers

Heath2

Hey, I am getting slow actions as well.

A refresh of my branch view takes around 7 seconds.
Viewing Uncommitted changes/working copy takes around 4 seconds.
A stash takes of a single file took 17 seconds.
Switching branches took 11 seconds

The list goes on. I am pulling from an SVN repo that has 1800 commits, 10,000 files.

luishdez

It's happening to me as well… on OS X Maveriks and mountain lion, project with more than 1000 commits. It becomes very slow… every time I made a change and focus the applicaiton it takes 10-20 seconds to refresh the list and show new changes if doesn't get frozen.

Peter Hultqvist

Almost all operations such as staging, checking out branches, reset branch are incredible slow.

Using the commandline(or gitk/git gui) they are instant( < 1 sec) but in Sourcetree those operations take 10 s.

This is a constant behaviour, it's always this slow.

I'm using windows 8 on an local ssd.

Keats .

hello,

same config and same symptoms.

tortoisegit is installed... can it interfere ?

Win8.1 & SSD

Filip Verhaeghe

Hi,

For small repositories, SourceTree is snappy. However, as our repo has crossed the 6 GB size large numbers of commits, SourceTree often takes 30 to 60 seconds to refresh. Running git commands on the command line takes a second or two.

I understand that SourceTree is displaying a lot of information, but SourceTree is unusable because of it. I wish SourceTree could be configured to be more focussed. Either by the ability to turn off the left and right panes, or by caching the information and updating it in a separate thread instead of blocking the main window. The toolbar remains active, but for instance in the commit window it again requests all the information again taking 10-20 seconds.

SourceTree 1.8.1 on Mavericks, all local SDD.

Filip Verhaeghe

I should perhaps mention that there are many many thousands of tags in this repository, so even displaying the tags has a significant cost to it.

I should also mention that `git status` is just fine in performance, as is `git add`, `git commit` and `git push`. So it is not the core operation of Git, but rather the usage.

When I said 10-20 seconds, that is actually a good case. In a bad case I conclude it is hung after many minutes of running.