Hacker News Reader

Comment by azag0 | Hacker News Reader

I use git often on the command line, especially for non-trivial tasks, but do not quite understand why someone would pick it for routine committing/tree view over a GUI. I find the ability to graphically see the state of the working tree and the index, and being able to stage/unstage individual lines by visual selection in a non-linear way absolutely natural. Likewise, the ability to get a context menu for a commit in a tree view and fire a command (rebase/branch most often) seems like something git was "built" for.

View on HN

I, on the other hand, am very uncomfortable using a GUI for such things, and find it extremely distracting to switch back and forth between the CLI and a GUI. Luckily, we both have options that do what we want and work for our particular tasks/skills/aptitudes/learning-style/whatever you want to call it.

I spend a lot of time in the commmandline, so it makes sense for me to not use a GUI. This alias (in ~/.gitcofig) is gold for most of the "graphical" stuff I'd use something like SourceTree for.

    [alias]
	lg = log --all --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%C(bold blue)<%an>%Creset' --abbrev-commit

I have these alias, plus :

    lg2 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all

The "--decorate" is key!

these are really good! I have this one..

  lg = log --graph --decorate --pretty=oneline --abbrev-commit

In Git's early history the vast majority of its users were people who significantly preferred the command line interfaces over GUI tools because they can be much quicker (if that is how you work normally at least) and easier to automate. In fact at first there were no GUI tools at all. There is an amount of momentum in tutorials being written for the command line, so people learn from the command line, so people write their procedures/tutorials/other from that perspective.

And it makes sense to learn the basics in its native form and then learn the useful trinkets that are added on top - then your initial learning is restricted to the core so you are learning that which is transferable to all Git front-ends rather than learning specific to a particular GUI.

The way advanced users tend to work in my limited experience (I'm am very much not an advanced user) is to use the command line for the basic day-to-day working and then the GUI tools when anything more complicated (large and/or partial merges) is required.

I'm so often doing stuff on remote servers that I don't want to rely on GUI tools for my daily work.

Also, GUI tools almost always expect you to use the mouse, which I prefer to avoid.

But I do often use Emacs Magit which gives me most of the benefits you mention over the CLI.

Because userskill is directly proportional to how many things you can do from a command line instead of a GUI. /s

I agree. It doesn't help that the git CLI is so awful. SourceTree is a much nicer interface (although it is too damn slow).

Have you looked at QGit? Yes it is very old - but is also still works fine.

Reply on news.ycombinator.com