As a note, gitg already watches for fs changes and reloads. It doesn't watch everything though, and it can clearly be a bit improved.

IMHO, automatical refresh can be annoying sometimes because it can give the feeling of uncontrolling the application, impredictable changes while an GUI like gitg is an interface where user give orders to machine, not a sort of monitor where machine refresh constantly a certain state.

I think it could be useful to list what automatical refresh are good and which are bad.

IMHO:
* refreshing the whole history is not good as it is CPU consuming, refreshing refs (branches, tags...) is quite enough
* refreshing commit view is complex because it will need to monitor the whole working directory
...

I agree that any auto-refresh operation must not consume a significant amount of CPU or other system resources - otherwise it's not worth doing.

I'm mostly interested in auto-refreshing refs.  It also might be possible to auto-refresh new commits cheaply without having to reread the whole history: when a ref has changed, maybe gitg could read the commit it points to, then follow the chain of parent commits until it gets to a commit it recognizes and then stop.  (I'm no expert on git, though, so I'd need to learn more about how git stores a repository before I could say confidently that this would be cheap).

Monitoring the whole working directory for files which have changed might not be so expensive, especially if we have a file monitoring mechanism that can inform us about changes in any directory or its subdirectories.

To clarify, it is not the monitoring of the file system that is expensive (you can easily recursively monitor a directory). The problem is that currently gitg cannot do incremental updates of the history. I wanted to have this for quite some time, for example also when you commit something in gitg, that you don't need to reload the whole history (you "simply" insert a commit at the top). Of course, this is not that simple because of the way the history tree algorithm in gitg works. It's worth investigating though.

I'd actually prefer to *not* see this implemented.  If you're learning git, or even if you're a git expert, it is helpful to be able to see the git history *before* a change is made, and then refresh it when you're ready to see how it affects the tree.  I've taught quite a few folks on Windows (using tortoise git) and I've showed them this technique so that can learn to understand what their changes will do to the "tree".

That's a good point, and I can see myself using that as a teaching tool as well. Could we make it an option then? I don't care what the default is (I can see both arguments already), but it would be nice to save me that extra step. I do a ton of repo management with branch rebasing, and there's a lot of ctrl+r as I git pull --all --prune from my terminal.

I think the common way to go about this (for example, in gedit we do this), is to notify the user that there were external changes and ask if he/she wants to refresh to see them. This way you can have the best of both worlds. Ideally, instead of refreshing the whole history or refs tree, you could show the transition to the new state, so that it's obvious what has changed. This is one area of UI where animations can actually be very helpful. I can imagine that newly inserted refs will be animated into the tree, same for history. We can experiment with the implementation of this.

Note btw that this report was made against the original gitg. The newly released gitg doesn't actually have file monitoring at all yet.

I've added monitoring of relevant files in .git and automatic updates of the various views. This is enabled by default, but can be disabled from the preferences.