Hacker News Reader

Comment by 9dev | Hacker News Reader

I haven't really used git on the command line for years now, except for some special cases. In my daily usage, I rely on the built-in IDE integration (IntelliJ, FWIW), and I don't understand why anyone would put up with doing it manually. I can do partial commits by selecting individual lines right in my editor. I can view all branches, merge them, cherry-pick from them, commit stuff or amend it, pull updates, edit tags - everything at once, with keyboard shortcuts.

Apparently, I'm in the minority here (also considering all the talk about git being such an essential skill that real programmers can issue commands blindfold). Why is that?

View on HN

Because I have always and will always prefer to interact with my VCS on the command-line.

The skillset is portable across environments (I can remote into a box and look at a repo as easily as I can interact with one locally), across editors (I don't have to learn and re-learn how each editor interacts with the VCS), and I can use all my familiar tools to work with it.

As for those workflow examples, I can just as easily do all those things via the command-line. The editor integration isn't anything special. And when I need to something weird and advanced (e.g. interacting with the reflog), odds are I'm gonna have to bust out those command-line skills, anyway.

Why would that be so hard to believe?

Edit: BTW, to be clear, I have no issues with people using GUIs. If you're productive with your tooling, who am I to judge? But you asked why, so I answered why. I don't claim my way is any better than your way.

It's not that it's hard to believe, I've seen enough discussion on this very topic to know many people (at least on HN) seem to prefer the CLI for VCS interaction.

I'm merely wondering why people seem to prefer a lower-level, separate tool to a higher-level, integrated one. To me it seems similar to writing your Makefile by hand vs. using automake.

The same as you, I don't want to dismiss anyone's tooling. Just curious :-)

I think there are two dynamics at play:

* Low-level tools come out and become robust sooner than high-level ones. It makes sense to learn them when no alternatives exist. Once alternatives are mature they're more effort to learn. I'm just much less fluent with an IDE than I am with the commandline, and the ubiquity of the commandline has meant I haven't been forced to learn to use the IDE well.

* There's some value to shaving off levels of dependencies. An IDE sends commands to git. There's just more moving parts and more to go wrong compared to just using git. When things go wrong, you don't have to understand two levels of error messages. Even when things are right, things can be slower. git is designed with obsession for large repos. Many UI screens might not scale as well as the underlying command providing them data.

In my experience most low-level people as you put it focus on the second reasoning. You don't use git in an IDE because you prefer to use Vim over an IDE, etc. But the first seems valid as well.

Scripting and automation are the goal ultimately. Working at the CLI supports that, GUI often doesn't. While I do like to see things in a GUI at times, ultimately it all gets encoded in scripts for automation and CI purposes. So terminals continue to be the focus.

I, on the other hand, have always and will always prefer to interact with my VCS via the editor-integrated plugin with GUI.

The skillset is portable across environments (I can remote into a box and look at a repo as easily as I can interact with one locally), and I can use all my familiar plugins from the extension marketplace to work with it. Yes, when I switch my favourite editor I'll have to relearn most of the particulars but that happens only about every 5 years or so, so it's fine.

As for those workflow examples, I can just as easily do all those things via the GUI. The shell integration isn't anything special. And when I need to something weird and advanced (e.g. interacting with the reflog), odds are I'm sure as hell NOT gonna have to bust out my command-line skills: from experience, 50% of the time I use some advanced commands, I mangle my repo into a broken mess that I am not exactly sure how to fix; not to mention that for routine tasks I keep re-doing "git status/diff" after every change because, again from experience, 10% of the time I issue slightly wrong commands.

No thanks, I'd stick with GUI which shows me what exactly I am going to modify and how. Would that be so hard to believe?

Now on a less facetious note: I prefer vi to ed, mc to naked shell, and gdb in dual mode (even though it routinely mangles my xterm's geometry into something non-Euclidean) to plain gdb for the same reasons — I can clearly see the state of the system that I am about to change, and the preview of the changes I am about to make, too. I don't have to second guess myself, or review the output of complicated shell pipelines with "echo" or "--dry-run" appended to the actual worker commands before actually committing to them.

> No thanks, I'd stick with GUI which shows me what exactly I am going to modify and how. Would that be so hard to believe?

It's not. That's, you know, why I specifically said "I don't claim my way is any better than your way."

> gdb in dual mode

The TUI feature?

Except you can't do that just as easily because the interface is worse

And you don't have to learn about each editor, just learn about one

And those command line skills can just be used in those advanced cases, that doesn't mean the 90% of the time you have to have worse experience

It's not hard to believe, it's just the arguments don't square

> It's not hard to believe, it's just the arguments don't square

Have you ever had a conversation like this?

Person A: Hey, what's your favourite food?

Person B: Pizza.

Person A: Really! Why?

Person B: I dunno, I just like the taste and the whole experience of eating it. But obviously that's just my opinion, and I totally get that some people might prefer something else.

Person A: Your argument doesn't square. Here, let me explain why your preference for pizza is wrong...

Instead of this irrelevant pizza example you could've tried to address the real issues with your arguments (hint: the one where you liked/prefered wasn't on the list)

I see I was too subtle, so I'll be direct: you seem to be confused because I'm not having an argument.

The question you might consider asking yourself is: why do you insist on trying to create an argument where none exists?

This is an incredibly bad habit. Arguing with people about their personal, subjective preferences when it's clear that person isn't inviting in an argument in the first place is incredibly annoying and it pisses people off. Don't do it.

You're repeating your mistake: I didn't argue about your subjective experience, but about your more objective justification of a particular workflow.

And you've turned a constructive conversation into off-topic pizza moralizing. Don't do it

(and of course you're having an argument, just a using poor arguments)

My experience with IDE integration is that it never implements the full feature set of the git CLI. It's probably improved, but I've generally found that anything besides basic clone/branch/commit/merge with very few developers and branches eventually leads to having to resort to the git CLI to resolve issues.

This is true of most IDEs, but you should really give IntelliJ's plugin a shot. It's far better at merge conflict resolution than using the CLI, which in turn makes even very complicated rebases easy. And it's more than capable of performing the most complicated git workflows I can imagine actually using in a real project (squash, cherry pick, rename, reorder, drop, apply patch, etc.).

The only time I ever reach for the CLI when I'm using IntelliJ is for `git bisect`.

I don't know about 'real' programmers, but I have an, admittedly, irrational fear of git GUIs doing the wrong thing. Even in Intellij, I open the built in CLI to interact with git. Old habits die hard :)

As they say, fear is the mind killer ;) if it helps: there is a Git tool window (not the VCS one) that has a Git Log tab, which shows the exact git command line IntelliJ executes. Gives a little peace of mind.

A lot of people who are starting out using git don’t understand how git works (what a commit is, what a branch is, what you can do to them). And they start to blame the CLI tool and start to hope that using the GitHub Desktop app will make everything make sense. This is the most common context where people say “you have to learn the git CLI.”

(Here’s an example from a few days ago from someone who proposes using GitHub Desktop in order to avoid learning git commands: https://www.reddit.com/r/learnprogramming/comments/15b7pra/s...)

Because I have two types of people who understand git on my team. People who use the CLI and people who don't understand git and just start clicking buttons

You forgot the people that only know: git commit -a -m "foobar" and think that's better than using a GUI to easily make clean commits.

If I could enforce one thing, it would be to REQUIRE partial commits for everything from an UI. I can't tell you the amount of commits I have seen that need to be cleaned up from spare debugging statements to vendor files to things that need to be added into the git ignore.

The other thing would be to make sure people understand what things like 'squash' and 'rebase' to and how they effect the tree.

Also to explain if you have multiple features, please don't work on it all on the same branch unless you have too. (This is a internal workflow, not really related to git but how we handle merges)...

Yeah, a UI could be just fine for an experienced git user. In my experience though, experienced git users don't use it though, so it's a moot point.

> from an UI

Just a really quick aside...

Do you... say "oooey" instead of "you eye" when reading "UI"?

I was annoyed by a lack of support for git worktrees in my current employer's dependency system (think virtualenv from python, but for everything). I fixed some scripts to be worktree dependent and tested it out thoroughly on the CLI, but as soon as I got the PR through with the change, I got a bazillion messages on Teams from people yelling at me that I broke their workflow.

Their workflow was basically "blindly point and click in Visual Studio because I don't understand even the basics of git. I miss the old custom in-house VCS and am very grumpy".

You're confusing "git" (which is relatively easy to understand and use) with "the git CLI" (which is a UX nightmare).

I learnt how to use git years before I learnt to use the git CLI.

It's because most Git GUIs are not especially good. There are a lot of them, the best ones aren't cross platform and some of the most popular are some of the worst.

I 100% agree with you that a GUI is by far the sanest way to do most git operations (I have yet to find an interactive rebase GUI that is better than a text editor). But if you just pick a random GUI it's probably going to be not very good.

Good GUIs I have discovered:

* GitX (Mac only) * GitExtensions (Windows only I think) * The VSCode Git Graph extension is basic but decent. Unfortunately it seems to have been abandoned.

I have tried many many others and they all sort of work but don't present things in an easy to follow way.

Give the IntelliJ integration a spin. It's really something else. Check out the merge conflict resolution manual for some impressions:

https://www.jetbrains.com/help/idea/resolve-conflicts.html

How well does your integration handle stacked PRs (if at all)? I find that the majority of my interaction with git is super basic that I get no value add replacing `git add -p` (esp. since I'm always in my terminal with Vim/tmux).

What _is_ annoying and something I could probably automate if I thought about it for more than a few minutes is when:

a) I have stacked PRs for isolation/workflow purposes in the form of: A <- B <- C

b) we use squash and merge

c) now when A gets merged I need to fix B and C because while the change set is the same the history is not (because of the squash & merge)

d) when B gets merged I have to fix C for the same reasons

> I rely on the built-in IDE integration (IntelliJ, FWIW)

That you're using IntelliJ makes a huge difference. VSCode's git integration is okay, but I honestly just reach for the command line if I'm using VSCode for a project. IntelliJ's, though, is hands down the best git UI out there. Even standalone apps can't compete with the convenience of having all the features bundled directly into your editor.

From what I've seen, a lot of people have tried git integrations in other IDEs and found that they are missing functionality and the features they do have aren't well done, so they assume that all git integrations will be the same. But as I've been reading through all the jj testimonials here, I can't help thinking that I already have all of this through the IntelliJ git plugin.

I have realized I have 15 years of git experience (incredible if true) and just got really, really used to it. Still excited if jj is a good follow-up since it sounds like it's not too far away from git's model.

Either it's employers who got tired of people not even knowing the basics of git (which would be common to any dvcs) and weren't productive as a result.

Or it's folks that think the base set of linux tools are the be-all-end-all of programming. ("Why use Dropbox when I can rsync", "Use the ext4 filesystem as a database and store metadata in inodes and use git for MVCC", "I will do sed | awk | cut | xargs find | tr instead of a 10 line python script").

Or it's folks that cult-follow one of the two groups above.

It's faster for me to interact with IntelliJ's git porcelain using key bindings than it is for me to switch to a terminal and write a command.

It makes fewer errors than I do. Besides forgetting syntax, fat fingering is a thing.

Conflict resolution is faster, easier, and less error-prone.

Pretty typical sorts of efficiency gains that IDEs can give.

Reply on news.ycombinator.com