Just received this IM from my friend, Nick:

11:48:58 AM Nick: kjsahfdlkjashdflkajshdflkjh
11:49:02 AM Nick: it was the git gui itself
11:49:09 AM Nick: it periodically refreshes
11:49:14 AM Nick: with a forked git process

Version control GUIs are uniformly evil. They entice you with a multitude of colors, and 1-pixel lines; their siren song is one-click commits and graphical 3-way merges.

But, like Odysseus, if we have any hope of prevailing, we must lash ourselves to the mast and steer past this temptation.

The real issue, of course, isn't the GUI per se, but the fact that a developer has virtually no idea what commands the GUI is issuing. I claim that any GUI which sufficiently exposes the underlying tool's features to know with confidence what clicking any button will do fails at being any more intuitive than the command line tool itself; and any tool which does not must by necessity contain hidden traps that an unwary developer will inevitably hit. Do not use GUIs for source control.

In 5 years, something like 90% of the source control mishaps I've seen can be attributed to GUIs hiding complexity of what they're doing. Git can be a beast to learn, for sure; but at least once you develop an intuition, you can be reasonably safe in performing even advanced operations at the command line tool, in a way I've never felt (or felt from co-workers) about GUI tools.

There is one place in which I think a GUI far outstrips the command line: read-only history and patch/diff viewing. I use GitX for this, though there may be others which are as good or better. (And, true to form, I always launch it from the command line with gitx.)