5 ms·

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

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.

9dev 3y ago
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 :-)
- akkartik 3y ago
  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.
- mixmastamyk 3y ago
  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.
Joker_vD 3y ago
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.
- deleted 3y ago
  [deleted]
- BaseballPhysics 3y ago
  > 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."
- trentnelson 3y ago
  > gdb in dual mode The TUI feature?
eviks 3y ago
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
- BaseballPhysics 3y ago
  > 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...
  - eviks 3y ago
    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)
    - BaseballPhysics 3y ago
      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.
      - eviks 3y ago
        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)

9dev 3y ago

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 :-)

akkartik 3y ago
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.
mixmastamyk 3y ago
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.

Joker_vD 3y ago

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.

deleted 3y ago
[deleted]
BaseballPhysics 3y ago
> 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."
trentnelson 3y ago
> gdb in dual mode The TUI feature?

eviks 3y ago

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

BaseballPhysics 3y ago
> 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...
- eviks 3y ago
  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)
  - BaseballPhysics 3y ago
    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.
    - eviks 3y ago
      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)