6 ms·

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,

by 9dev 3y ago

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?

calvinmorrison 3y ago
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
- Double_a_92 3y ago
  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.
  - calvinmorrison 3y ago
    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.
    - BaseballPhysics 3y ago
      > from an UI Just a really quick aside... Do you... say "oooey" instead of "you eye" when reading "UI"?
      - calvinmorrison 3y ago
        UI
- _huayra_ 3y ago
  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".
- IshKebab 3y ago
  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.
BaseballPhysics 3y ago
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.
porridgeraisin 3y ago
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.
codexb 3y ago
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.
- lolinder 3y ago
  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`.
matwood 3y ago
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 :)
- 9dev 3y ago
  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.
lolinder 3y ago
> 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.
nkjnlknlk 3y ago
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
MatthiasPortzel 3y ago
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/should_i_know_git_in_2023_even_there_is_already/ https://www.reddit.com/r/learnprogramming/comments/15b7pra/s...)
kzrdude 3y ago
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.
Clamchop 3y ago
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.
IshKebab 3y ago
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.
- 9dev 3y ago
  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 https://www.jetbrains.com/help/idea/resolve-conflicts.html
deleted 3y ago
[deleted]

by 9dev 3y ago

calvinmorrison 3y ago

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

Double_a_92 3y ago
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.
- calvinmorrison 3y ago
  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.
  - BaseballPhysics 3y ago
    > from an UI Just a really quick aside... Do you... say "oooey" instead of "you eye" when reading "UI"?
    - calvinmorrison 3y ago
      UI
_huayra_ 3y ago
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".
IshKebab 3y ago
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.

BaseballPhysics 3y ago

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.

porridgeraisin 3y ago

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.

codexb 3y ago

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.

lolinder 3y ago
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`.

matwood 3y ago

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

9dev 3y ago
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.

lolinder 3y ago

> 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.

nkjnlknlk 3y ago

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

MatthiasPortzel 3y ago

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/should_i_know_git_in_2023_even_there_is_already/ https://www.reddit.com/r/learnprogramming/comments/15b7pra/s...)

kzrdude 3y ago

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.

Clamchop 3y ago

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.

IshKebab 3y ago

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.

9dev 3y ago
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 https://www.jetbrains.com/help/idea/resolve-conflicts.html

deleted 3y ago

[deleted]