6 ms·

If you editor has a correct git support, you never need to do git status because it will show you which files had been edited since the last commit. Every time

by hv42 8y ago

If you editor has a correct git support, you never need to do git status because it will show you which files had been edited since the last commit. Every time I hear people saying how much they prefer the git command line is because they never seriously tried to leverage the git features of their IDE. Vs code with git lens or intellij idea have excellent git integration. Everything is one shortcut away. The git commands that are used are log into a console if you want to check. At the end of the day both methods work, it's just a matter of preference but it is worth trying a good git UI. Also if you ever try to teach someone git, it's not as intuitive as you think [1]. Having a consistent UX can help. That's why there is definitely a space for this kind of git UI as presented in the article. [1]http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/

kelnage 8y ago
In my experience of using git integration features in IntelliJ, they are nice for simple tasks like quickly checking the status of a file or committing all the changes, but as soon as I need to do more complex tasks in git, I find the UIs either get in the way and slow me down or just aren’t fully featured enough to do what I need to do and I end up back on the command line. Hence why I always encourage newcomers to git to learn both if possible. I do agree that git could certainly do with a more consistent command line interface - but I imagine that won’t even be considered until that next major version of git, if it ever arrives.
- Normal_gaussian 8y ago
  Git integration in IntelliJ is terrible IMO. It conflates staging and committing, and unstaging with reverting. I don't use it because it is a PITA, but what is even more annoying are the PR's from team members who do use it, which I have to send immediately back due to random files.
  - korm 8y ago
    The history features are incredible and also the only ones I use, eg diffing, showing changed dirs/files/lines, blame, file/dir commit history. I've never used it for anything else git related because the ui is strange.
  - Rjevski 8y ago
    True, but frankly it is Git’s model that is broken, or at the very least overcomplicated. I do not care whether files are staged or not up until the point I actually want to commit, so personally the IntelliJ way of doing it is perfect.
jolmg 8y ago
> If you editor has a correct git support, you never need to do git status because it will show you which files had been edited since the last commit. I prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically? Git is only tangentially related to file editing, so it doesn't really make sense for an editor to know anything specifically about it. > Every time I hear people saying how much they prefer the git command line is because they never seriously tried to leverage the git features of their IDE. But I am! The whole OS is my IDE. Seriously though, I've done fugitive in vim and magit in emacs. After some time of using them almost exclusively, I've decided it's better to use the shell. It's not because I haven't tried more "integrated" ways of programming, but because I find that the flexibility/power that comes with treating every feature of an IDE as a separate program in an OS environment is better. EDIT: Added more comments.
- imdsm 8y ago
  > I prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically? I agree with this. Strongly.
- int_19h 8y ago
  > I prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically? Because it's convenient. IDEs work with files. Git manages files. Ergo, IDEs should support Git.
- BoiledCabbage 8y ago
  > I prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically? That's similar to saying "a smart phone is a smartphone" why not have one device to take calls, and another to store contacts, another to browse the web, another to listen to music. It's ergonomics. Many things are more efficient when integrated.
abhishekjha 8y ago
I do a git diff after every git status before adding/committing. Do IDEs show diff before committing? Jetbrains IDEs do show diff between subsequent commits. Although they do highlight which files have been modified.
- int_19h 8y ago
  > Do IDEs show diff before committing? Not as part of the same operation, but the usual workflow is that there's a pane in the somewhere that lists all modified and staged files, and you can click on those to see diffs (or just click "commit" if you don't care).
singingfish 8y ago
My IDE is bash. I use almost always use emacs -nw for editing text. While there are git front ends for emacs, I almost never bother with them. I can't remember what I've memorised about the git CLI, but usually I don't find the CLI troublesome. YMMV.
laumars 8y ago
> Every time I hear people saying how much they prefer the git command line is because they never seriously tried to leverage the git features of their IDE. I have used IDEs but I still prefer the CLI client. Like with most things in IT, GUIs are great for simple things but the CLI is more expressive and exposes more options. Then once you've spent enough time using the CLI tools it's sometimes more jarring to switch between the GUI and CLI than it is to just use the CLI for simple tasks that could easily be done in the GUI.
k_ 8y ago
I only expect my editor to read some information from my git repository. Gutters displaying new/modified hunks and shortcuts to jump to them are pretty much the only things I find useful (for my use; I understand some will find other features helpful). But any action I want to be made on the repository, I do it myself. I have some exceptions though, like if I want to revert the hunk I have the cursor on it's nice to be able to revert (or even stage, but I still use `git add --patch` for that) it with one shortcut.
throwaway0255 8y ago
> Every time I hear people saying how much they prefer the git command line is because they never seriously tried to leverage the git features of their IDE. I think this statement is much more powerful in reverse. People who prefer the git features of their IDE have probably never seriously tried to leverage the features of git... I prefer the git command line. It supports every single feature of git, and as an interface it’s completely and totally frictionless. People trying to create tools and UX around git usually do so under the false impression that git is the source of friction, when really they are. > Also if you ever try to teach someone git, it's not as intuitive as you think [1]. Having a consistent UX can help. Are there people who need this kind of help learning, but then go on to do well at it? I’ve found programming in general is extremely binary. Either you’re the kind of person that can grasp it and has the motivation to track down answers yourself and hack away, or you aren’t. Being able to pick up a new system or technology and understand it very quickly is what it means to be a programmer, even more so than the act of programming itself in my opinion. I think trying to find shortcuts around that to teach people is a bit of a catch-22.
sbr464 8y ago
I turned off everything, autocomplete (the auto drop down menu style), the status bar, line numbers, git gutter, color changes from git in the tree view, live linting. Main thing enabled is auto format on save, and a bunch of 1-2 letter aliases for common commands. My editor is a sea of calm tranquility now.
onion2k 8y ago
If you editor has a correct git support, you never need to do git status because it will show you which files had been edited since the last commit. Unless you're on someone else's machine. Then you'll still need the cli.
- c17r 8y ago
  In that case one should stick to using vanilla git with no aliases, shortcuts, etc.
dominotw 8y ago
> intellij idea have excellent git integration. I find all the colors and ques distracting while I am coding.
jehlakj 8y ago
I used the ide interaction then moved to the terminal once I realized there are really only a subset of commands you need to know. There are visual things that are still handy that the ide does, but to perform commands, I feel like the terminal is more explicit and you know what subsequent steps you’re taking (relatively, of course). Same with vim. Too many options. Poor UX. Eg. Why are there two way to scroll down? Just use ctrl-d which helps you retain the context of the code you’re navigating.

by hv42 8y ago

kelnage 8y ago

In my experience of using git integration features in IntelliJ, they are nice for simple tasks like quickly checking the status of a file or committing all the changes, but as soon as I need to do more complex tasks in git, I find the UIs either get in the way and slow me down or just aren’t fully featured enough to do what I need to do and I end up back on the command line. Hence why I always encourage newcomers to git to learn both if possible. I do agree that git could certainly do with a more consistent command line interface - but I imagine that won’t even be considered until that next major version of git, if it ever arrives.

Normal_gaussian 8y ago
Git integration in IntelliJ is terrible IMO. It conflates staging and committing, and unstaging with reverting. I don't use it because it is a PITA, but what is even more annoying are the PR's from team members who do use it, which I have to send immediately back due to random files.
- korm 8y ago
  The history features are incredible and also the only ones I use, eg diffing, showing changed dirs/files/lines, blame, file/dir commit history. I've never used it for anything else git related because the ui is strange.
- Rjevski 8y ago
  True, but frankly it is Git’s model that is broken, or at the very least overcomplicated. I do not care whether files are staged or not up until the point I actually want to commit, so personally the IntelliJ way of doing it is perfect.

jolmg 8y ago

> If you editor has a correct git support, you never need to do git status because it will show you which files had been edited since the last commit. I prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically? Git is only tangentially related to file editing, so it doesn't really make sense for an editor to know anything specifically about it. > Every time I hear people saying how much they prefer the git command line is because they never seriously tried to leverage the git features of their IDE. But I am! The whole OS is my IDE. Seriously though, I've done fugitive in vim and magit in emacs. After some time of using them almost exclusively, I've decided it's better to use the shell. It's not because I haven't tried more "integrated" ways of programming, but because I find that the flexibility/power that comes with treating every feature of an IDE as a separate program in an OS environment is better. EDIT: Added more comments.

imdsm 8y ago
> I prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically? I agree with this. Strongly.
int_19h 8y ago
> I prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically? Because it's convenient. IDEs work with files. Git manages files. Ergo, IDEs should support Git.
BoiledCabbage 8y ago
> I prefer sticking to the Unix way. An editor is an editor. Why should it support git specifically? That's similar to saying "a smart phone is a smartphone" why not have one device to take calls, and another to store contacts, another to browse the web, another to listen to music. It's ergonomics. Many things are more efficient when integrated.

abhishekjha 8y ago

I do a git diff after every git status before adding/committing. Do IDEs show diff before committing? Jetbrains IDEs do show diff between subsequent commits. Although they do highlight which files have been modified.

int_19h 8y ago
> Do IDEs show diff before committing? Not as part of the same operation, but the usual workflow is that there's a pane in the somewhere that lists all modified and staged files, and you can click on those to see diffs (or just click "commit" if you don't care).

singingfish 8y ago

My IDE is bash. I use almost always use emacs -nw for editing text. While there are git front ends for emacs, I almost never bother with them. I can't remember what I've memorised about the git CLI, but usually I don't find the CLI troublesome. YMMV.

laumars 8y ago

> Every time I hear people saying how much they prefer the git command line is because they never seriously tried to leverage the git features of their IDE. I have used IDEs but I still prefer the CLI client. Like with most things in IT, GUIs are great for simple things but the CLI is more expressive and exposes more options. Then once you've spent enough time using the CLI tools it's sometimes more jarring to switch between the GUI and CLI than it is to just use the CLI for simple tasks that could easily be done in the GUI.

k_ 8y ago

I only expect my editor to read some information from my git repository. Gutters displaying new/modified hunks and shortcuts to jump to them are pretty much the only things I find useful (for my use; I understand some will find other features helpful). But any action I want to be made on the repository, I do it myself. I have some exceptions though, like if I want to revert the hunk I have the cursor on it's nice to be able to revert (or even stage, but I still use `git add --patch` for that) it with one shortcut.

throwaway0255 8y ago

> Every time I hear people saying how much they prefer the git command line is because they never seriously tried to leverage the git features of their IDE. I think this statement is much more powerful in reverse. People who prefer the git features of their IDE have probably never seriously tried to leverage the features of git... I prefer the git command line. It supports every single feature of git, and as an interface it’s completely and totally frictionless. People trying to create tools and UX around git usually do so under the false impression that git is the source of friction, when really they are. > Also if you ever try to teach someone git, it's not as intuitive as you think [1]. Having a consistent UX can help. Are there people who need this kind of help learning, but then go on to do well at it? I’ve found programming in general is extremely binary. Either you’re the kind of person that can grasp it and has the motivation to track down answers yourself and hack away, or you aren’t. Being able to pick up a new system or technology and understand it very quickly is what it means to be a programmer, even more so than the act of programming itself in my opinion. I think trying to find shortcuts around that to teach people is a bit of a catch-22.

sbr464 8y ago

I turned off everything, autocomplete (the auto drop down menu style), the status bar, line numbers, git gutter, color changes from git in the tree view, live linting. Main thing enabled is auto format on save, and a bunch of 1-2 letter aliases for common commands. My editor is a sea of calm tranquility now.

onion2k 8y ago

If you editor has a correct git support, you never need to do git status because it will show you which files had been edited since the last commit. Unless you're on someone else's machine. Then you'll still need the cli.

c17r 8y ago
In that case one should stick to using vanilla git with no aliases, shortcuts, etc.

dominotw 8y ago

> intellij idea have excellent git integration. I find all the colors and ques distracting while I am coding.

jehlakj 8y ago

I used the ide interaction then moved to the terminal once I realized there are really only a subset of commands you need to know. There are visual things that are still handy that the ide does, but to perform commands, I feel like the terminal is more explicit and you know what subsequent steps you’re taking (relatively, of course). Same with vim. Too many options. Poor UX. Eg. Why are there two way to scroll down? Just use ctrl-d which helps you retain the context of the code you’re navigating.