Almost everytime I use "Pull" or "Push" from a Git repo, Sourcetree takes a long time, even when the changes are small.
I know this isn't enough information for a useful bug report. How can I help troubleshoot this problem?
Hmm, that's one I haven't seen before, the beach ball shouldn't happen because the real pull is done in the background. Perhaps it's some follow-up process that's usually very fast but isn't in this case.
If you go into Preferences and check the box 'Always show full output', then this dialog will show more detail of all git processes (and require you to manually close it on completion instead of it happening automatically), so this might give us more information about where exactly this is happening. Please can you try this and let me know what it shows, ie when the beachball happens in relation to this more detailed dialog and the contents of the output?
It should just be waiting for the pull here and not actually doing anything in the main thread that would cause the beachball, I can't reproduce this here. Can you confirm:
If you have the opportunity, if you Can open Activity Monitor and use the Sample Process on SourceTree while the beachball is present that might help. Thanks
This is actually the simplest of all options then since all the authentication will be handled internally by SSH, without any interference by SourceTree. Therefore once 'git pull' has been called, all the processing is entirely confined to git and ssh, with SourceTree just waiting for output / completion events in the background, so the beachball is very puzzling.
Apple did change the version of OpenSSH in Mountain Lion, can you recall whether this issue appeared when you upgraded from Lion, if you used SourceTree across the upgrade? I haven't seen this issue myself in testing, but I only have 10.8 on a test boot right now due to a bug in which caused builds signed on 10.8 to have keychain issues on certain OS versions.
I've been doing some testing here and I can't reproduce this on 10.7.5 or 10.8.2, using Bitbucket as a remote and authenticating git via SSH keys. In all cases the push / pull behaves as expected and I never see a beach ball. My 10.8.2 machine is basically a fresh install so I had to set up my keys etc but it worked flawlessly.
My test machine is a 2010 i5 MacBook Pro with a non-SSD hard drive, fairly modest configuration so I don't think it's atypical.
Is there anything else that might be unusual about your machine or the repo? As in machine specs, whether you're using macports or something else which might have installed a custom SSH, particularly huge repo etc?
The machine is a mid 2010 Macbook (2.4 GHz Core 2 Duo) upped to 8 GB RAM.
I don't use Macports, but I'm using Git 1.8.0 from Homebrew. SSH is OS X standard.
Pulling/pushing to Bitbucket is somewhat slow - I've just cloned another copy of this repo to get this info:
$ time git clone email@example.com:internetgroup/vulcano.git Cloning into 'vulcano'... remote: Counting objects: 7256, done. remote: Compressing objects: 100% (4395/4395), done. remote: Total 7256 (delta 2222), reused 3135 (delta 820) Receiving objects: 100% (7256/7256), 26.21 MiB | 285 KiB/s, done. Resolving deltas: 100% (2222/2222), done. git clone firstname.lastname@example.org:internetgroup/vulcano.git 1,09s user 0,48s system 1% cpu 2:07,98 total
I'm clutching at straws now because I just can't reproduce this behaviour, but have you tried using the system git in SourceTree instead? Just incase something about the repo is semi-dependent on the newer version you have from homebrew or something.
I just got the beachball after a push, right after "updating local tracking ref 'refs/remotes/origin/master'" (and before the "Completed successfully"). I managed to capture the output of Activity Monitor's Sample Process: Sample of SourceTree.txt
Thanks, this basically nails down exactly what was happening. SourceTree is responding to a notification from FoundationKit which is saying "there's more output available from the git task". This is because SourceTree basically fires off the push then asks the OS to tell it when there's more data to display - it does this precisely to avoid spinning taking up resources, not blocking and so not creating a beachball scenario.
However what's happened here is that FoundationKit has subsequently sent SourceTree the 'more output is available' notification, but when SourceTree asks for that output, it hasn't responded quick enough to avoid the beachball. This is not SourceTree waiting on output when it shouldn't, because it's only asked for it when specifically told there's more to read right now. The OS is just not delivering on its promise of the available output quickly enough. I've never seen this happen before even on old machines.
I basically have no way to avoid this except perhaps to put in a timeout / retry loop in the place where I respond to the OS notification. All this would do though is keep the beach ball from appearing (it wouldn't actually make the process go any faster, since ST can only proceed when the OS gives it the output it claimed was ready), and it might actually make things worse, since if I/O bottlenecks are the problem then ST may keep joining the back of the queue on retry.
The only reason I can imagine that this would happen is that your machine is extremely I/O constrained, to the point where the ability of the OS to service requests for I/O are not keeping up with the events that are raised to say I/O is ready. Do you have anything running on your machine that could be stressing I/O in particular?
Thanks for the detailed explanation. The workaround you suggested does sound like it could make matters worse.
AFAIK I'm not running anything that could be stressing I/O (even thou I usually have lots on open apps), but I'll try to keep an eye on I/O when I see the beachball in ST.
It's a shame that iotop on OS X is so flaky, do you have any suggestions to monitor I/O usage by process?
OS X I/O is usually really, really solid, which is why I'm surprised you're seeing this, I certainly haven't encountered it before (I test on a 2007 MBP too and it doesn't demonstrate this issue).
You can use 'sudo fs_usage' to monitor disk I/O and you can add processes parameters to filter it. In this case, SourceTree isn't technically waiting on file I/O, just inter-process I/O, but maybe there will be something there that gives a clue anyway, since the OS uses the same pool of 'file' handles in either case.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hey everyone! My name is Natalie and I'm an editor of the Atlassian Blog and I've got a question for you: What's your favorite quote about teamwork? We've compiled a list here, along with...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs