SourceTree hides history while refreshing
Asked by David Potter:

I encounter this problem many times a day while using SourceTree. When I switch focus to a SourceTree git repository window and click on a branch (e.g. develop), it clears the history and then some time later it shows it. Sometimes this only happens after switching to a different view and then switching back.

For background, the git repository has two remotes, one hosted on a Mac server on our LAN specified using an IP address, and one on GitHub. I have probably 30 or 40 total repositories listed in the Bookmarks window.

This has become more and more of an annoyance, making SourceTree - one of my favorite tools, by the way - less and less useful, even painful to use.

Let me know if there is anything you'd like me to provide to you to troubleshoot this problem.

Thanks,  
***David***


Answers:
author: stevestreeting
body: SourceTree auto-refreshes by default, and judges when it should refresh based on kernel file events it receives from Mac OS X. However, it never acts upon these 'dirty' events while it is in the background - this is to avoid taking CPU time away from foreground tasks, you can imagine that when doing bulk operations you wouldn't want SourceTree to be refreshing all the time. The downside of this is that when you switch back to SourceTree, any queued refresh events then kick in, meaning you tend to always see them. It's a balance, but this ended up being the most useful in practice. The history is cleared during the refresh because it may well be invalid because of the pending changes (particularly in git which supports history modification), and on very large repositories the delay may cause confusion and potentially errors if old data were displayed.

If you don't like this behaviour, you can disable the auto-refresh either globally in Preferences, or per repository. Then, SourceTree will only refresh when you tell it with Cmd-R.

comments: author: David Potter
body: Actually, I think you've done a very nice job of autorefresh in the app. I especially like that you don't refresh the UI when the app is in the background (not the foreground app). I wish Xcode would do the same :-).

The behavior I am describing occurs even when I press Cmd-R. The problem is that for the repositories I am using it takes a long time - on the order of 10 to 30 seconds, sometimes longer - to show the history again. I would actually rather it show the old history than nothing at all. That history will always be right, it just might not be complete.


author: stevestreeting
body: OK, thanks :) There's actually quite a lot of silent tuning going on in the background there, from deciding what events to ignore to throttling them under load (say if you have SourceTree in the foreground but also have a bulk action going in the background). No-one ever notices of course, but it's nice that you like it ;)

I see your point, I have a couple of very large repos which are similar. I guess I'm just being over-cautious, becuase I have had the case where people have done history-changing modifications and then clicked something which no longer exists. If you never do this then it's not an issue, but it definitely happens. Perhaps either some kind of 'yeah, I'll take the risk' option or some smarter handling of those edge cases is in order. Although, we'd still need a way to indicate that the refresh is in progress, otherwise you could be sitting there wondering if it's really refreshing or not.


author: David Potter
body: I like the idea of a message that comes up when doing one of those actions while a refresh is in progress. I also like the idea of some indication of an in progress refresh. I see the activity indicator in many places during refresh, e.g. in the Working Copy panes, and I thought there was an activity indicator somewhere on or near the history during a refresh but I don't see it now.

Keep up the good work. This is my favorite software development tool.


author: stevestreeting
body: Yeah, actually the progress indicator used to be in the Jump to: area, but when I re-optimised that to load itself on demand separately that got lost. I've actually put a more obvious progress indicator back in 1.4.1.1 which is out now.

Thanks for the positive feedback! I've logged this for future work here: <https://jira.atlassian.com/browse/SRCTREE-1002>


author: David Potter
body: This refresh behavior is really getting out of hand for me. Will you be addressing this soon?

Thanks,  
***David***


author: stevestreeting
body: We've focussed on general optimisation so far in the 1.5 point releases but I'll escalate this.


author: Alex Davies
body: Obligatory "me too!!!" comment...

It is completely infuriating to see something I want to click, click it, only for it to disappear and make me wait before clicking it again. My machine is powerful, please let it just update in the background.


author: stevestreeting
body: FWIW the original reasoning was that in a world of rebasing, that commit you just clicked may not exist anymore. But I guess it's better just to let the occasional error happen in that rare case.


author: David Potter
body: Ah, that makes sense. For me, the hidden history is happening so much as to make the tool very difficult to use right now that I would gladly accept an occasional error :-).

Thanks for considering our feedback. I really appreciate how responsive you are. This is a tool I use every day, all day.


author: Gabe da Silveira
body: I'm running into the problem that it is refreshing constantly even while I'm using the app and not doing anything else. I'm not sure what would be triggering the kernel events (something in MacVim? maybe Command-T polling the filesystem?). In any case, it makes it impossible to select lines to stage because they keep getting deselected as it refreshes every second or so. I've disabled the refresh for this reason alone, but otherwise liked the auto-refresh.


author: stevestreeting
body: This is definitely that some tool is continuously writing data to disk, which is raising file events which ST is acting on. Qt Designer is one I'm aware of that does this. To avoid this you can disable SourceTree's automatic refresh feature, either for a single repo (the Settings option in the repo window in question) or globally for all repos (in Preferences). From then on ST will only refresh when performing specific state-changing events itself, or when you press Cmd-R.