SourceTree 1.5 beta 1 refreshes its the commit log an awful lot sometimes

Paul Hoepfner-H

I think this is probably the same behaviour as the previous version of SourceTree, I just happen to be using 1.5 beta 1.

Sometimes I'm working in my git working copy (and I usually have a couple git working copy windows open), and just browsing around, doing whatever, and SourceTree will refresh the commit log like once every few seconds. It'll refresh in all open windows, too, not just the one I'm actively using. I'm just seeing that spinner going on, and going off, going on, and going off, sometimes 5-6 times. I can't figure out what's triggering it.

For it to refresh once between major actions (e.g., committing, switching branches, applying a stash), I can understand. But 3-4 times? Any idea why it's so frequent? It's kind of distracting and seems unnecessary. It seems to me that SourceTree could be streamlining its git operations into one chunk - issuing one apparent refresh, from my point of view - instead of having it broken up into many refreshes.

Plus it doesn't need to refresh the windows that aren't active, just the one I'm actively working in. But it will do refreshes everywhere. It feels like a waste of CPU time and it's pretty darn distracting from my workflow.

I have that checkbox "refresh when files change" turned on in Preferences, which I think I want to keep on. I'm not even changing files for these refreshes to happen so often. There's also that "check remotes for updates every 10 minutes" setting, which seems like a good idea to me - but I'm hoping that if nothing has changed since the last check of the remotes, I don't have to see that spinner. It should just silently refresh in the background if nothing's changed, in my opinion. Same goes for the "refresh when files change" setting - don't show me the spinner if nothing's changed.

Maybe I'm asking too much. I just find this behaviour to be more distracting than it is in GitHub for Mac, which I think just does its refreshes once when the app regains focus, or you switch views or something.

stevestreeting

You probably want to update, we're on 1.5.2 now.

We do try to keep these refreshes to a minimum - SourceTree acts on kernel file events, which it batches up in segments of 3 seconds. This is designed to be fast enough not to have a significant perceptible lag when a file changes and you expect ST to refresh, but also not to refresh too many times. We also do things like suppressing events when doing major tasks like Clone, caching timestamp information about the internal state of the repo to try to avoid refreshing more than we need to, and detecting 'flood' events like when you're doing a build. Unfortunately there's a limit to how much we can eliminate though - the typical case of multiple refreshes is because the kernel is busy and delivers file events spread out over more than 3 seconds, even though they're from the same source. If we've already started acting on one, and it's in an area we can't differentiate (the .git/.hg structures are quite deep and we can't record them all), we can't tell that the subsequent event is from something else.

To be honest though, I rarely see more than 2 refreshes traceable to actual events - usually it's just after startup as the results from the remote repo query start coming in; most of the time it's one. I'm on a 2010 MBP here with an i5.

If you prefer not to have auto-refreshing, you can turn it off in preferences or even per-repository. We only refresh when SourceTree has the focus, and buffer file events that happen while in the background to avoid chewing CPU when not the foreground - this is often why you see a refresh when you switch back if something has changed. Turning off the auto remote refresh will avoid the log refreshing to pick up background fetched data too, it's up to you. Just refreshing on gaining focus is OK, but either misses things and ends up needing a manual refresh button, or refreshes unnecessarily if you switch back and forth a lot. The use of kernel file events isn't perfect either, especially because OS X will only tell you the folder that changed and not the specific file, but it's the most responsive that we found.