23 ms·

> This is a fantastic demonstration of why i exclusively use git from a command prompt... Thanks for this. I've always felt the same way but haven't been able

by kbd 8y ago

> This is a fantastic demonstration of why i exclusively use git from a command prompt... Thanks for this. I've always felt the same way but haven't been able to put my finger on why. As more things get integrated into my editor (I use VSCode) I feel like I should use the shiny features, but for source control I think I'm going to only use the commandline forever. (Edit: though plugins such as GitLens that give you source control info inline are fantastic.) Along with some nice features I've added, such as my 'git af' (add + fzf) shortcut[1][2], the commandline is very usable (don't have to 'git add' and type filenames manually). [1] https://github.com/kbd/setup/blob/65b3d0abcb34540b43880792e8f7512ee0ec1abd/HOME/.config/git/config#L44 https://github.com/kbd/setup/blob/65b3d0abcb34540b43880792e8... [2] https://github.com/kbd/setup/blob/65b3d0abcb34540b43880792e8f7512ee0ec1abd/HOME/bin/gsf https://github.com/kbd/setup/blob/65b3d0abcb34540b43880792e8...

pstadler 8y ago
Same here w/o fancy tooling around Git, but a couple of aliases. I will refuse to use any Git tools or UIs, but the standard CLI, until the end of my career. Besides that, my IDE/Editor is neither a build tool manager nor should it run my app from within an integrated console having specific settings. The projects people are going to inherit from me will always be editor-agnostic, the environment they run in will never depend on a certain setup that can‘t be documented clearly and they will always run within an isolated context, i.e. the project root.
- idontpost 8y ago
  God bless you.
- ascagnel_ 8y ago
  I agree on part of that -- VSCode has a pretty good Node debugger, and you can run it with a listen hook (and therefore set it to run via a npm/yarn package.json script). Similarly, I feel like it's OK for an editor to run a script from the app in an integrated terminal, as long as that script is still accessible from a standard CLI. Git is complex enough that I don't trust more complex operations (basically anything beyond push, pull, add, and checkout) to be handled by a GUI, but a GUI can make for a great code review tool.
sdegutis 8y ago
Yesterday I came across a screencast I made in 2009 back when Xcode had separate windows for the console and the editor[8], and Interface Builder was a completely separate program external to Xcode. One of the things that stuck out to me was the silly "SCM" option in the NSOutlineView on the left side[2], which I had absolutely never touched. And I remembered from my more recent experiences using Xcode that its git integration is not very useful and overly simplistic. So I started wondering why Apple would even want to add such a useless feature into an otherwise really powerful and useful editor, even back then in Xcode 3. And I imagined this scenario where they were brainstorming and someone higher up in the Xcode team was like "ok guys, I got word from above that 'source code' is becoming a big thing now, and we need to add it somewhere" and someone was like "how about the project navigation list?" and someone else maybe piped up "but it doesn't really fit hierarchically in the metaphor" and someone else was like "dude it's 4:30pm some of us have families to get back to can we just forget about the metaphorical inconsistencies?" and they just added it as an expandable item. I use Xcode and VS Code ever day, and I absolutely never use the Git functionality in either of them. I tried both for a few weeks each, but absolutely nothing compares to Magit[4]. Not even command line. For git, Magit is the same secret weapon that pg claimed Lisp was for programming. [2] https://i.imgur.com/DYJN12N.png https://i.imgur.com/DYJN12N.png [4] https://magit.vc https://magit.vc [8] https://i.imgur.com/lXcGpDh.jpg https://i.imgur.com/lXcGpDh.jpg
btashton 8y ago
I also very much related to this, the two exceptions I find awkward from the command line are: * Doing partial adds with `git add -p`. I see the hunk it presents see what I want from it, but then sometimes have to go through several iterations of splitting, skipping etc.. A visual tool (even like the tool in vim-fugitive) is a huge improvement. At the end of the day I'm still looking at the staged diff before committing * Looking at diff or blame logs. Once again these are super low risk for unexpected behavior, and for larger changes that span multiple files, I find the shiny editor features make it easy to see the context quickly.
- akavel 8y ago
  There's a somewhat hidden gem in vanilla git which can be sometimes useful: git gui You can right-click on some line in the file and select "Stage Hunk for commit", etc. instead of `git add -p`. It can be also helpful for browsing history, esp. "blame digging".
  - lgunsch 8y ago
    I love git gui. I've used it for more than 5 years now. Has an ugly UI, but it's very functional and complete.
  - btashton 8y ago
    Interesting I did not know about that. Seems like it is part of the git suite, but usually packed separately (Fedora it is the git-gui package) and requires gitk.
Drdrdrq 8y ago
> don't have to 'git add' and type filenames manually Another option is git add -p, which asks you about each change so you can review them once more and maybe leave some (parts of) them for future commits.
- kbd 8y ago
  Yep I have a 'git ap' alias set up for that :)
aaaaaaaaaab 8y ago
Hint: git add -i
- kbd 8y ago
  That is not close to the same thing.
- allannienhuis 8y ago
  I use git commit -a a lot - it's most often the exact thing I want to do, with the exception of adding new files.
Shorel 8y ago
Even if I use git exclusively in the command prompt, I usually have a working copy where I edit files, and another copy that's read only where I switch branches without care, do the binary search bisect thing and so on. I don't remember what happened for me to start doing this, but it saves so many headaches that I don't care. All the graphic Git clients cause me panic. I have Sublime-Merge has a read only thing, because it shows diffs in a nice format. But I am still not ready to commit something from it.

by kbd 8y ago

pstadler 8y ago

Same here w/o fancy tooling around Git, but a couple of aliases. I will refuse to use any Git tools or UIs, but the standard CLI, until the end of my career. Besides that, my IDE/Editor is neither a build tool manager nor should it run my app from within an integrated console having specific settings. The projects people are going to inherit from me will always be editor-agnostic, the environment they run in will never depend on a certain setup that can‘t be documented clearly and they will always run within an isolated context, i.e. the project root.

idontpost 8y ago
God bless you.
ascagnel_ 8y ago
I agree on part of that -- VSCode has a pretty good Node debugger, and you can run it with a listen hook (and therefore set it to run via a npm/yarn package.json script). Similarly, I feel like it's OK for an editor to run a script from the app in an integrated terminal, as long as that script is still accessible from a standard CLI. Git is complex enough that I don't trust more complex operations (basically anything beyond push, pull, add, and checkout) to be handled by a GUI, but a GUI can make for a great code review tool.

sdegutis 8y ago

Yesterday I came across a screencast I made in 2009 back when Xcode had separate windows for the console and the editor[8], and Interface Builder was a completely separate program external to Xcode. One of the things that stuck out to me was the silly "SCM" option in the NSOutlineView on the left side[2], which I had absolutely never touched. And I remembered from my more recent experiences using Xcode that its git integration is not very useful and overly simplistic. So I started wondering why Apple would even want to add such a useless feature into an otherwise really powerful and useful editor, even back then in Xcode 3. And I imagined this scenario where they were brainstorming and someone higher up in the Xcode team was like "ok guys, I got word from above that 'source code' is becoming a big thing now, and we need to add it somewhere" and someone was like "how about the project navigation list?" and someone else maybe piped up "but it doesn't really fit hierarchically in the metaphor" and someone else was like "dude it's 4:30pm some of us have families to get back to can we just forget about the metaphorical inconsistencies?" and they just added it as an expandable item. I use Xcode and VS Code ever day, and I absolutely never use the Git functionality in either of them. I tried both for a few weeks each, but absolutely nothing compares to Magit[4]. Not even command line. For git, Magit is the same secret weapon that pg claimed Lisp was for programming. [2] https://i.imgur.com/DYJN12N.png https://i.imgur.com/DYJN12N.png [4] https://magit.vc https://magit.vc [8] https://i.imgur.com/lXcGpDh.jpg https://i.imgur.com/lXcGpDh.jpg

btashton 8y ago

I also very much related to this, the two exceptions I find awkward from the command line are: * Doing partial adds with `git add -p`. I see the hunk it presents see what I want from it, but then sometimes have to go through several iterations of splitting, skipping etc.. A visual tool (even like the tool in vim-fugitive) is a huge improvement. At the end of the day I'm still looking at the staged diff before committing * Looking at diff or blame logs. Once again these are super low risk for unexpected behavior, and for larger changes that span multiple files, I find the shiny editor features make it easy to see the context quickly.

akavel 8y ago
There's a somewhat hidden gem in vanilla git which can be sometimes useful: git gui You can right-click on some line in the file and select "Stage Hunk for commit", etc. instead of `git add -p`. It can be also helpful for browsing history, esp. "blame digging".
- lgunsch 8y ago
  I love git gui. I've used it for more than 5 years now. Has an ugly UI, but it's very functional and complete.
- btashton 8y ago
  Interesting I did not know about that. Seems like it is part of the git suite, but usually packed separately (Fedora it is the git-gui package) and requires gitk.

Drdrdrq 8y ago

> don't have to 'git add' and type filenames manually Another option is git add -p, which asks you about each change so you can review them once more and maybe leave some (parts of) them for future commits.

kbd 8y ago
Yep I have a 'git ap' alias set up for that :)

aaaaaaaaaab 8y ago

Hint: git add -i

kbd 8y ago
That is not close to the same thing.
allannienhuis 8y ago
I use git commit -a a lot - it's most often the exact thing I want to do, with the exception of adding new files.

Shorel 8y ago

Even if I use git exclusively in the command prompt, I usually have a working copy where I edit files, and another copy that's read only where I switch branches without care, do the binary search bisect thing and so on. I don't remember what happened for me to start doing this, but it saves so many headaches that I don't care. All the graphic Git clients cause me panic. I have Sublime-Merge has a read only thing, because it shows diffs in a nice format. But I am still not ready to commit something from it.