Hacker News Reader

Comment by iLoch | Hacker News Reader

I just don't understand why people use the git CLI. Git is too powerful a tool, using the CLI limits one of two things: your capabilities, or your productivity.

Often times I see my coworkers screwing around with git trying to review diffs and commit their changes. One of two things happens: they spend longer than they should doing it, or they do it haphazardly. Sometimes they get it wrong.

Just use a GUI.

I use SourceTree and often find myself committing individual lines or chunks in my files instead of the whole file. I'm confident the average git CLI user doesn't even know this is possible. I can do massively complicated commits with ease because I can see every single line that has changed right in front of me.

I just don't understand the fetishization of source control via CLI. In all likelihood it doesn't make you more productive, and it's probably less accurate unless you really know you way around git.

View on HN

As a counterpoint, every time I've tried a git GUI (I've tried lots), I end up bashing my head against it within a few minutes. They usually make very basic things easy and anything even slightly outside the box basically impossible.

I'm much more productive using a couple of git commands that I can type in a few seconds, rather than hunting for things in menus and dialogs for ages.

> committing individual lines or chunks in my files instead of the whole file

That's really git 101. I'd expect if you haven't learned to do that via the CLI then maybe you gave up too soon and jumped straight to GUI? `git add -p .` is very easy to use.

[GUIs] usually make very basic things easy and anything even slightly outside the box basically impossible.

Whereas in the CLI, complex operations are difficult but possible; trivial operations are also difficult but possible. :)

did you try magit?

Maybe it is of limited use for non-emacs users, but imho it's a fantastic way to use git with a perfect balance between making simple things very easy to do and allowing (almost) anything you can do with the CLI while providing excellent visual feedback.

I also found the git plugin [1] in the Sublime Text Package Control repository to be rather useful. The basic idea is similar to magit, with the (subjective) upside of avoiding the crazy Emacs hotkeys.

That said, since I discovered Spacemacs, I'm also enjoying using Magit - the "evil" control scheme for it is great, too.

[1]: https://packagecontrol.io/packages/Git

magit is a marvelous piece of work indeed, and the thing that keeps me going back to Emacs every time I get curious about some other editor.

But yeah, I picked it up after quite some time working in Emacs, and the keybindings feel natural. Perhaps it would be very different for somebody new to Emacs.

i use a gui for two things:

1. gitk is the handiest way to undo the occasional accidental commit ("reset index, leave working tree untouched"). yes, i know there's bound to be a CLI way; no, i can't be bothered to look it up and remember it when i have gitk right there and it's not a mainstream use case.

2. git-cola does interactive commits way better than the console interface does.

> I can do massively complicated commits with ease because I can see every single line that has changed right in front of me.

You mean `git diff`? I'm sure it comes down to a matter of preference, but claiming that using git from a command line slows you down or limits your capabilities only makes sense if you rarely touch a command line (a bit strange for a developer). Plain old git from the command line is functional and actually quite user friendly. Add your own aliases and some kind of git shell and you can fire off a complicated commit as fast as you can sensibly review your diff — all without lifting a finger from the keyboard.

GUI git tools are nice for visualizing feature branches, but for the basic day-to-day workflow the CLI is much more productive.

> Git is too powerful a tool, using the CLI limits one of two things: your capabilities, or your productivity.

Surely the exact comment, with the roles of 'CLI' and 'GUI' switched, could be made without anyone necessarily noticing. The anecdotal evidence of what works, and doesn't work, for you should not, I think, be regarded as any particular evidence of what does work for anyone else, much less what can work for everyone else. (As has already been pointed out, your child posts are full of responses from people with other experience.)

Agree with this 100%. If you can do everything you want on the CLI then more power to you, but in my experience people using the CLI for diffs/staging include unrelated code in their commits at a much higher rate. I checkout/branch/pull/push in the CLI, and use Git Tower to diff and stage.

I would wager this goes beyond just `git`, and is more a statement about CLI vs. GUI, which IMO just comes down to preference, and how much you're really willing to learn one vs. the other.

There are definitely people out there (I've seen them) that would be better served with a GUI because they really can't be bothered to learn how to use the `git` CLI well (Or just use `git` well in general). But at the same time I'm tons more productive with the CLI vs. GUI.

> I just don't understand why people use the git CLI. Git is too powerful a tool, using the CLI limits one of two things: your capabilities, or your productivity.

That's fine, but on the other hand, a typical GUI limits both your capabilities and your productivity.

About the only interface I prefer over git CLI is magit in Emacs. It's unlike your typical GUI, because you don't have to click at anything (keyboard-operated), and it exposes like 99% of git inside a well-thought-out text-based UI that adds just the right amount of interaction and editor integration. Using magit is incredibly efficient, much faster than even using CLI git.

> I just don't understand the fetishization of source control via CLI. In all likelihood it doesn't make you more productive, and it's probably less accurate unless you really know you way around git.

If you don't know your way around git, chances are you're going to seriously screw things up via GUI and you'll have no idea what happened or how to fix it. Starting from CLI is a good way to actually learn the tool, which I believe is crucial regardless of what interface you'll eventually be using.

> I'm confident the average git CLI user doesn't even know this is possible.

Your sibling commenters disagree.

In that case, I'll support his conjecture by admitting that I didn't know that was possible. I'm a pretty average git user, if not actually using it slightly more than my peers (many of whom are only switching from subversion to git within the last 3-4 years). But the rate at which I become more proficient in git is extremely slow - you have to go out of your way to learn more about git most of the time. Maybe a GUI would help in that particular aspect, since I could see unknown options and experiment with them.

As someone in pretty much the same boat, try SourceTree or the like. I still use Git from the command line, but it really opened my eyes on what Git can do.

I agree with this 100% when it comes to creating commits. It makes it easy to create sensible commits with only the changes relevant to the individual commit. You can see what's staged and tailor it quickly. I'm a heavy terminal users and I agree that in general committing from the CLI seems like using the wrong tool for the job.

That said, there's a lot you can't do easily or at all from the GUI. Rebases, surgically reverting a series of commits from a bad merge, re-writing branches, blame, bisect, reviewing the history of a single file, checkout of a specific version of a file from a previous revision; there are a lot of things that I can do easily from the CLI that I don't know how to do or don't care to do from a GUI.

Use the right tool for the job. The GUI is great for common tasks and the CLI is great when you need more power.

No gui that I have seen can deal with the GIT workflows in an efficient manner. Most GUIs are slow. Rethink GIT workflows and make them worse. I only use a GUI for this: - GitX for adding and reviewing files to a commit. (partial commit support is also very nice).

the rest is command line git.

With command line completion is pretty good and fast.

I used to be in your camp before I discovered git add -p. Allows you to interactively pick which hunks to stage. SourceTree essentially replicated the same workflow in a nice GUI.

Yeah that's what I used to think but you have at understand that typing and keeping your fingers on the keyboard is often way faster than moving around and clicking various regions of the screen.

Then what happens when they update their GUI? Oh you have to learn it all over again.

That being said, I do on occasion open a GUI if I have to do a complicated merge or something like that but for basic operations why would you need it.

Unfortunately, nome of those neat git GUIs work on Linux...

Not true: https://www.gitkraken.com/download

Propietary, requires an account and mergetool is behind a paywall (although this is not as significant). Ouch.

SmartGit is wonderful - I've used it for years - and it works on Linux, macOS, and Windows.

http://www.syntevo.com/smartgit/

If you use Emacs, check out magit. It's not really a GUI but it is git integrated into emacs so you can do all the usual functions, view diffs, write commit messages, etc. all from within emacs.

Reply on news.ycombinator.com