I actually used to think similarly before I found git up -- although to me it wasn't about switching window context away from the terminal but rather switching away from the text editor. I imagined that the ideal place for featureful visualization/interaction with the repo would be in the text editor/ide. In reality though -- i really like having the separate window -- it's always there, does one thing and does it well, and it's easy to switch to when I want to take a look at the state of my repo/upstream branches/any dirtiness in my checkout (what exactly have I done recently?). I regularly use three editors when working on different platforms -- Xcode, android studio, atom -- sometimes it's convenient to use in ide repo-driven features (blame, sometimes historical diffs for a single file), however very often I'm actually more interested in quickly seeing diffs for files other than the one(s) I'm currently editing -- so switching to a separate app context that's all about showing repo info tends to be the fastest way to see the relevant info I want side by side without changing away from the editing context I want. More often than not navigating to most relevant diffs within the ide would actually involve more expensive context switching -- for me I'm discovering that it's always somewhat high risk to switch editor contexts -- editing text is just such a powerful interface that it tends to easily lead down rabbit holes that take me further from the most relevant info for my current task context. Once I have the most useful buffers in the right windows, with maybe some reasonable things in the editor navigation stack -- changing the editor views at that point comes with a pretty high risk of straying off task -- or operating for awhile with the non optimal set of editor windows in front of my face -- which at some point I'll realize is dumb/wastes energy and fix -- but energy was already spent in the meanwhile ...

Honestly I'm not aware of any common repo tasks that I could more efficiently complete via the command line vs gitup. There are good keyboard shortcuts for everything in gitup so most everything I do doesn't even involve the mouse.

Also -- I'm the kind of person who's always got a set of terminal windows open and definitely uses them often (almost never use Finder, hate taking my hands off the keyboard to reach for the trackpad). At this point -- I never reach for the git cli over gitup (except when cloning a new repo).

That's interesting. On Linux?

I'm using mac at the moment, and the awful window management (and inability to properly change it - all wm apps just handle resizing and moving within existing spaces and margins) just makes me more motivated to do everything in full-screen tmux, to simulate a decent wm - as long as everything is CLI-based!

(I tried Arch on it for a while, but ended up deciding the firmware difficulties - in particular the battery draining quickly and CPU running hotter - weren't worth it; I traded i3 for full-screened tmux.)

For commands maybe, but nothing beats a graphical history tree. It's hard for a human to imagine a complex branch history without a good visual aid

I agree, and often use a `log --bunch -of --options` alias to view this - but slightly prettier rendering isn't going to make me switch window and back again.

I can't think of a single time I've actually ever cared to look at anything other than a linear history or a single file's blame. I do have a 'hist' alias set up (http://blog.wittchen.biz.pl/basics-of-git/#gist16617665), but it's not something I ever actually use.

Good for you. I'm probably not as smart and more likely to get confused without having the history laid out in the form of a clean, coloured graph. At any rate, it allows me to free whatever brain power I have for other purposes