5 ms·

Amen. The ever-present insistence that the command line is the only way to use git is the modern version of "ed is the standard text editor"[1] https://www.gnu

Amen. The ever-present insistence that the command line is the only way to use git is the modern version of "ed is the standard text editor"[1] https://www.gnu.org/fun/jokes/ed-msg.html https://www.gnu.org/fun/jokes/ed-msg.html

pixelpoet 2y ago
Bothers me a lot that you're getting downvoted. Bunch of elitists who insist that cmdline is only way to get things done (everyone has to study cmdline options because who could possibly have multiple 4k screens for some visual options dialog?), probably using GDB in 2025 and having massive Stockholm syndrome about it, ...
- skeeter2020 2y ago
  I don't consider myself a very core or talented developer, but I do feel quite strongly that git from the cmd line is much easier than a GUI, but overall ridiculously hard regardless. The abstractions and visualizations in graphical interfaces is either too dense & complicated, or more likely hides what's actually happening; there's no way to reduce the inherient complexity. My take: don't play the game. learn your basic required workflow from the command line and use the decent documentation to look up everything else.
  - mjburgess 2y ago
    NB. I did explicitly say a GUI on top of a cli app is a broken approach. Your intuition comes from this -- that the git API is cli-first. Source control should be designed graphically first, with a cli to automate. I routinely use tree-view and column view in macos finder to think-through fs organisation -- doing this as a sequence of cli commands would be masochistic. Notice how all the best vcs tutorials are just providing basic visuals which would be better as the interface.
    - skydhash 2y ago
      The thing that CLI have over GUI is programmability, which for programmers is a valuable property. As for me, any repeatable task, I automate away with various degree of effort and quality. If I find myself needing a particular set of commands and flag, I create an alias, a function, or a shell script for that, like `flac2mp3.sh` instead of hunting down through the shell history. For most vcs tutorial, they don't often use why the history of changes is important, instead focusing on a set of usual commands. Why, not how. Once you have that philosophy down, the tool usage become much more efficient.
    - dingnuts 2y ago
      I've been using magit for almost a decade now and it directly contradicts what you're saying simply by existing and being as awesome as it is
      - alwayslikethis 2y ago
        I thought I would be just fine with the CLI but I was amazed by magit. A GUI can work well if it leans into the strengths of GUIs - discoverability of features and showing state. Magit does all of these exceptionally well. It helps that git's CLI is quite poorly designed with a lot of unintuitively named commands. How do you undo a commit? How to unstage a file? What's a stash? What's the difference between log and reflog? With magit I've been able to do things I wouldn't bother before, like reverting small parts of hunks from past commits, doing partial staging of files (not including all changes), and dealing with stashes effectively.
- perching_aix 2y ago
  I'm one of those folks who will tell people to give the official CLI frontend of git a chance and to try and stick to it. I can assure you it is not out of elitism, but experience. I've tried the many third party GUI frontends, and always got myself into bigger trouble down the line in the end, nor did they bring any of the revelatory boosts in insight they claimed they would. And of course, they're all a little different from one another, so migrating between them is an additional chore. Then of course it's possible I didn't give the many GUI frontends enough of a chance. Such is life, it's a resource limited game. Principally, I justify my position with the argument that the many GUIs will try to translate git into something visual by adding their own designs, and this can prove additionally misleading and difficult, if git wasn't rough enough already. The only GUI bits I use for git are editor integrations such as the official one in VS Code, and only when I know it's adequate. Which you can only know if you know what's going on in the background.
  - ninetyninenine 2y ago
    GUI is absolutely easier for merge conflicts. I use the one that comes on jetbrain ides which is awesome. This isn't even opinion. It's fact. Anyone who has experience regularly(keyword) using both CLI and GUI for merge conflicts will side with me on this by an overwhelming majority such that I might as well call this fact.
    - perching_aix 2y ago
      The community seems to disagree so far. I'll take a look at how it works tomorrow though. For me most of the misery around merge conflict resolution stems from how git fundamentally works, so I'm not sure how much it can possibly improve on it.
      - ninetyninenine 2y ago
        The only people who disagree are people who don't have regular experience from both sides. Graphical diffs that automatically handle merge conflicts visually with clicks to insert, undo and the ability for custom modification are MUCH MUCH more convenient with a GUI. Highly recommend the jetbrains conflict resolver gui. I can assure you ANYONE who regularly has experience with both the CLI and that GUI(jetbrains) will hands down say the GUI is superior for merge conflicts. It is NOT intrinsic to the nature of merge conflicts. Any disagreement in this area stems from lack of experience or knowledge. If anyone has experience with both and they have a contrary opinion, feel free to tell me. I doubt such a person exists though.
- suzzer99 2y ago
  I work in a lot of repos at once. I do a lot of global search-and-replacing and random debugging. With SourceTree, I can easily see all the changes I've made across all repos in one glance. I can then drill down to each file with the visual diff and see whether the changes are something I want to check in, or just debugging. If it's debugging code, I can click "Discard Changes" to drop all changes I've made to that file. Or I can selectively discard a hunk or discard lines. When I show these features to command line purists, they always concede that this can't easily be done with the command line. So I don't see what's to gain if I'm losing those features, which I rely on constantly. I've been working in SourceTree for a decade, so I know all the quirks by now, which I pass on to any new devs who want to use it.
  - fragmede 2y ago
    > can't easily be done with the command line. git add -p ?
    - metaltyphoon 2y ago
      Learning the -p was the biggest gain I’ve had after years of using git via cmdline only.
      - suzzer99 2y ago
        Which is kind of the point. If a GUI editor does this stuff for you, that seems like a win over incrementally learning these little command line tricks that save you a bunch of time.
        metaltyphoon 2y ago
        That’s fine for some and I have no problems with it but my mind doesn’t work that way and instead it asked “how is possible the UI is doing this”. All of that lead to learning what hunks are and manually editing them to learn.
      - greg5green 2y ago
- TeMPOraL 2y ago
  There's a really good argument to use plaintext - it lends itself to very efficient use through searching, matching and replacing, whether interactively or in bulk. The lack of structure and semantics in a pure plaintext representation is often a curse, but sometimes a blessing. At the same time, I'll go further than you, GP and GGP - I'd say that insisting on coding in plaintext, specifically on always directly reading and editing the same plaintext, single-source-of-truth representation of a program, is fundamentally limiting our ability to manage complexity, and makes people waste a lot of time on faux-problems like "lots of small vs. few big functions", or "exceptions vs. result types", etc. FWIW, plaintext is still okay for most coding use cases - it's trying to fit everything into the same source code and somehow keep it readable that's an impossibility.
- blueflow 2y ago
  GUI's are bad for expressing tasks beyond some level of complexity.
- milesrout 2y ago
  It bothers me a lot that you're complaining about downvotes when the comment you are replying to isn't even greyed out let alone flagged dead. It bothers me a lot that you can't discuss something like this without turning it into personal attacks. People can't just have different preferences than you. No it has to be "elitists" with "stockholm syndrome". This kind of rhetoric is unbecoming of this forum and destroys amicable discussion. Have you considered that maybe people use the command line because it is better for them, and they recommend it to others because in their view, you'll need it eventually so why not learn now? You can visualise a git history with a gui tool while still learning the command line interface btw. They aren't mutually exclusive. Do you just use scratch too? Or are you one of those elitists using textual programming languages? Must be stockholm syndrome...

pixelpoet 2y ago

Bothers me a lot that you're getting downvoted. Bunch of elitists who insist that cmdline is only way to get things done (everyone has to study cmdline options because who could possibly have multiple 4k screens for some visual options dialog?), probably using GDB in 2025 and having massive Stockholm syndrome about it, ...

skeeter2020 2y ago
I don't consider myself a very core or talented developer, but I do feel quite strongly that git from the cmd line is much easier than a GUI, but overall ridiculously hard regardless. The abstractions and visualizations in graphical interfaces is either too dense & complicated, or more likely hides what's actually happening; there's no way to reduce the inherient complexity. My take: don't play the game. learn your basic required workflow from the command line and use the decent documentation to look up everything else.
- mjburgess 2y ago
  NB. I did explicitly say a GUI on top of a cli app is a broken approach. Your intuition comes from this -- that the git API is cli-first. Source control should be designed graphically first, with a cli to automate. I routinely use tree-view and column view in macos finder to think-through fs organisation -- doing this as a sequence of cli commands would be masochistic. Notice how all the best vcs tutorials are just providing basic visuals which would be better as the interface.
  - skydhash 2y ago
    The thing that CLI have over GUI is programmability, which for programmers is a valuable property. As for me, any repeatable task, I automate away with various degree of effort and quality. If I find myself needing a particular set of commands and flag, I create an alias, a function, or a shell script for that, like `flac2mp3.sh` instead of hunting down through the shell history. For most vcs tutorial, they don't often use why the history of changes is important, instead focusing on a set of usual commands. Why, not how. Once you have that philosophy down, the tool usage become much more efficient.
  - dingnuts 2y ago
    I've been using magit for almost a decade now and it directly contradicts what you're saying simply by existing and being as awesome as it is
    - alwayslikethis 2y ago
      I thought I would be just fine with the CLI but I was amazed by magit. A GUI can work well if it leans into the strengths of GUIs - discoverability of features and showing state. Magit does all of these exceptionally well. It helps that git's CLI is quite poorly designed with a lot of unintuitively named commands. How do you undo a commit? How to unstage a file? What's a stash? What's the difference between log and reflog? With magit I've been able to do things I wouldn't bother before, like reverting small parts of hunks from past commits, doing partial staging of files (not including all changes), and dealing with stashes effectively.
perching_aix 2y ago
I'm one of those folks who will tell people to give the official CLI frontend of git a chance and to try and stick to it. I can assure you it is not out of elitism, but experience. I've tried the many third party GUI frontends, and always got myself into bigger trouble down the line in the end, nor did they bring any of the revelatory boosts in insight they claimed they would. And of course, they're all a little different from one another, so migrating between them is an additional chore. Then of course it's possible I didn't give the many GUI frontends enough of a chance. Such is life, it's a resource limited game. Principally, I justify my position with the argument that the many GUIs will try to translate git into something visual by adding their own designs, and this can prove additionally misleading and difficult, if git wasn't rough enough already. The only GUI bits I use for git are editor integrations such as the official one in VS Code, and only when I know it's adequate. Which you can only know if you know what's going on in the background.
- ninetyninenine 2y ago
  GUI is absolutely easier for merge conflicts. I use the one that comes on jetbrain ides which is awesome. This isn't even opinion. It's fact. Anyone who has experience regularly(keyword) using both CLI and GUI for merge conflicts will side with me on this by an overwhelming majority such that I might as well call this fact.
  - perching_aix 2y ago
    The community seems to disagree so far. I'll take a look at how it works tomorrow though. For me most of the misery around merge conflict resolution stems from how git fundamentally works, so I'm not sure how much it can possibly improve on it.
    - ninetyninenine 2y ago
      The only people who disagree are people who don't have regular experience from both sides. Graphical diffs that automatically handle merge conflicts visually with clicks to insert, undo and the ability for custom modification are MUCH MUCH more convenient with a GUI. Highly recommend the jetbrains conflict resolver gui. I can assure you ANYONE who regularly has experience with both the CLI and that GUI(jetbrains) will hands down say the GUI is superior for merge conflicts. It is NOT intrinsic to the nature of merge conflicts. Any disagreement in this area stems from lack of experience or knowledge. If anyone has experience with both and they have a contrary opinion, feel free to tell me. I doubt such a person exists though.
suzzer99 2y ago
I work in a lot of repos at once. I do a lot of global search-and-replacing and random debugging. With SourceTree, I can easily see all the changes I've made across all repos in one glance. I can then drill down to each file with the visual diff and see whether the changes are something I want to check in, or just debugging. If it's debugging code, I can click "Discard Changes" to drop all changes I've made to that file. Or I can selectively discard a hunk or discard lines. When I show these features to command line purists, they always concede that this can't easily be done with the command line. So I don't see what's to gain if I'm losing those features, which I rely on constantly. I've been working in SourceTree for a decade, so I know all the quirks by now, which I pass on to any new devs who want to use it.
- fragmede 2y ago
  > can't easily be done with the command line. git add -p ?
  - metaltyphoon 2y ago
    Learning the -p was the biggest gain I’ve had after years of using git via cmdline only.
    - suzzer99 2y ago
      Which is kind of the point. If a GUI editor does this stuff for you, that seems like a win over incrementally learning these little command line tricks that save you a bunch of time.
      - metaltyphoon 2y ago
        That’s fine for some and I have no problems with it but my mind doesn’t work that way and instead it asked “how is possible the UI is doing this”. All of that lead to learning what hunks are and manually editing them to learn.
    - greg5green 2y ago
TeMPOraL 2y ago
There's a really good argument to use plaintext - it lends itself to very efficient use through searching, matching and replacing, whether interactively or in bulk. The lack of structure and semantics in a pure plaintext representation is often a curse, but sometimes a blessing. At the same time, I'll go further than you, GP and GGP - I'd say that insisting on coding in plaintext, specifically on always directly reading and editing the same plaintext, single-source-of-truth representation of a program, is fundamentally limiting our ability to manage complexity, and makes people waste a lot of time on faux-problems like "lots of small vs. few big functions", or "exceptions vs. result types", etc. FWIW, plaintext is still okay for most coding use cases - it's trying to fit everything into the same source code and somehow keep it readable that's an impossibility.
blueflow 2y ago
GUI's are bad for expressing tasks beyond some level of complexity.
milesrout 2y ago
It bothers me a lot that you're complaining about downvotes when the comment you are replying to isn't even greyed out let alone flagged dead. It bothers me a lot that you can't discuss something like this without turning it into personal attacks. People can't just have different preferences than you. No it has to be "elitists" with "stockholm syndrome". This kind of rhetoric is unbecoming of this forum and destroys amicable discussion. Have you considered that maybe people use the command line because it is better for them, and they recommend it to others because in their view, you'll need it eventually so why not learn now? You can visualise a git history with a gui tool while still learning the command line interface btw. They aren't mutually exclusive. Do you just use scratch too? Or are you one of those elitists using textual programming languages? Must be stockholm syndrome...