Hacker News Reader

Comment by scarface74 | Hacker News Reader

I love git, but the learning curve seems very high for the unititiated. Git seems to work best as the assembly language of source control for a lot of people. It's okay as long as you put a nice GUI on top of it.

Even though I'm pretty comfortable with git thanks to attending a two day workshop conducted by a guy from Github, I still like using tortoise git.

View on HN

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.

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.

I use a combination of command line and GUI. From the command line, using git for commit, add, status, push, pull, fetch, branch, add remote and rm is just clearer, quicker and more straightforward in many cases.

From any of the IntelliJ derivatives I'll tend to do add, commit, push and diff just because it's a clean interface where I'm already working. I've never really like any of the standalone 3rd party tools though. They just never felt like they gave me anything all that useful.

I'd love to find a better third-party UI for git too. Or, I've found SourceTree or the GitHub app (not the latest Electron release, albeit) hard to work with when doing a lot of stuff outside the typical add/commit/push, so I've slowly ended up learning the command line over the years.

I've seen others get in situations with fussy merge conflicts or a detached HEAD and be clueless why the UI isn't working properly. I can't blame them though, since git can be complicated and a tool like SourceTree has to make things nicely-abstracted to be helpful/productive. It's hard to know what details to make explicit/simplify, and I think with git there's a lot of work we could still do.

Git really needs something on par with Mercurial's TortoiseHg - it actually manages to express all the edge cases in a natural fashion, and lets you jump from cmd line to gui and back with ease (it's more of a cmdline tool that happens to invoke gui dialogs).

I've been looking for years to find something like it for git. Nearest I've seen was GitKraken, but it's UI is still horribly opaque, can't invoke from cmdline in nearly the same way, and requires me remotely authenticate (!?) to use it :|

GitKraken is my favorite UI, and they publish a number of videos to try to break down how features might be best used, supports Git Flow natively, etc.

Yeah -- I use sourcetree almost exclusively. Why would I want to type 'git status' and then 'git diff long/path/to/my/file.txt' when I could just click on the file in the changes list?

To see a diff of that file I'd you could just type gst or git diff l and hit tab in zsh until I get to the path I want. Takes me a short time, I don't have to move my hand away from the keyboard and I can use my aliases if I want to. I feel like for my day-to-day work, the CLI works faster and better than all of the GUI tools I see. Also, it's available on every machine I touch (colleagues and juniors when help is needed). I just find it more valuable in my day-to-day workflow compared to GUI stuff.

Because it's possible to be much faster on the command line than you'll ever be clicking around on a GUI.

if you are already using a GUI for your IDE, is it really faster typing on the command line than right clicking on your git root folder in explorer -- that in my case is usually on a different monitor -- and clicking on git commit where you can see all of your changes, and then double clicking on a file to bring up your diffs?

Don't get me wrong, knowing the command line is invaluable when it comes to corner cases that just don't work well in a GUI and automating tasks.

Yep, it's absolutely faster - a command line is simply more responsive than moving a mouse and clicking dialogs if you know exactly what you need to do. I've always used an IDE but I exclusively use the command line for VCS. Setting up a commit is much easier to do if you know all the commands over the tedious drag/right click/choose dialog.

As to your use case, git diff has never failed me.

This is all aside from the fact that the CLI is ubiquitous. One day you'll be in a situation where it's all you have access to, and you'll thank yourself for having learned it (or kick yourself for not).

When would I only have access to the command line as Windows developer? The most I would have to do from a command line in my usual day to day work is use git pull to automate my deployments. But in that case, I also need to know the ins and outs of msbuild. That doesn't mean I'm going to use a regular old text editor and build with msbuild in my daily workflow.

Maybe in the general case, but not in the scenario I outlined above. What if there are 20 files I touched? I'll need to type each of the 20 paths to view each individual diff. And that's if I view each diff only once, which I don't typically do.

I understand the value of being familiar with your tools, but sometimes the CLI just isn't the right one.

EDIT: btw, I use the vim plugins in all of my work (VS, VSCode), so I'm not shy when it comes to learning curves.

>git diff

Gets all the differences between your current unstaged changes vs your head, no need for typing 20 individual paths

Good to know, although I'm still not impressed with its presentation when doing larger diffs.

Then use a different `diff` app, such as the wonderful graphical kdiff if you're on KDE. You can find the differ that you like and then set `git` use it as a default.

Then we're back to using a GUI, which is what I was arguing for in the first place lol

True, but a graphical differ I'll concede could be easier to use than a CLI differ for some people. But a full graphical Git environment is horrible. I've seen my Windows-using colleagues use them. Shudder.

By the way, you might want to look at the `--diff-word` option.

No, it's faster using the keyboard to operate a GUI.

Reply on news.ycombinator.com