Hacker News Reader

Comment by methodin | Hacker News Reader

It's sad so many people use GUIs on top of git - you really end up not understanding what git is doing and it can lead to problems. Command line is supreme for the same reason that a majority of books are better than their movie counterparts. They are easier, though, but in the case of git that isn't a good thing.

View on HN

I agree, but this is a symptom of a larger problem.

Really I'm disappointed that people don't build their computers from scratch these days. You don't know what's going on when you have so many components joined together with random blobs of firmware.

Give me a bare Z80, a bunch of RAM, and anybody could understand it. Plus if you're writing your code in assembly you can optimize better than any compiler - they wouldn't know enough to use your opcodes as constants when you need to.

Honestly that just sounds way too complicated... I do it all in my head.

To think I've been writing all my code out on paper. I need to get on your level. /s

I'm skeptical that you actually learn more by using the command line vs. a GUI. Yes, if you need to do something subtle, you might have to learn something, and you might need to use the command line to do it. But you learn more because you need to, so you go out and learn it, not because the command line teaches you something.

To me knowing the CLI is a little like knowing how to read sheet music. It makes analysis and collaboration a lot easier.

You can put down a sequence of git invocations in a text file or script, stare at them, reason about them, tweak them as appropriate for your use case, copy and paste them to another developer, write about them in a blog post, include them in a README.

It's harder to do this with a sequence of gui actions.

And how often in a normal dev workflow do you need to do that?

Most developers, pull, push, merge, rebase, and fix merge conflicts.

Yes I agree, but installing tortoise GIT and then looking at what commands are available on the menus is a great way to focus learning when you don't know whats to learn yet.

I think it really depends on the use cases. For example, if you are in a team of 5 engineers, all working on mostly unrelated areas, then no problem. In this case, you might go a long way without having an actual need to learn something more advanced.

However, it's quite important to recognize when your basic git skills are not enough anymore. Which often is joining a bigger team/company.

"Learning something more advanced" is usually knowing how to fix conflicts, merge, and rebase. That can all be handled with the GUI. Even when you screw up, learning how to use the reflog can be done from the GUI.

What can't be done from the GUI? The only thing I've had to do from the command line is using git subtrees.

From a GUI or any GUI? There are many, many GUIs implementing git and not all of them do it right or even well. A GUI is an abstraction and implementers are free to do it however they see fit. Not to mention having to deal with bugs in two separate systems.

>There are many, many GUIs implementing git and not all of them do it right or even well.

Speaking of that, which git GUI is good, in your opinion? I tend to use Git from the command line, but had tried out a few GUIs for a project earlier, but not enough to decide. GitEye was one, another might have been SourceTree (IIRC it is from Atlassian).

I completely agree with you, but to be fair, magic it is really convenient to use. But then again, it doesn't really try to "hide" git's workflow as much as other tools do.

Reply on news.ycombinator.com