11 ms·

There are some warts, but it seems nice from afar. The biggest wart is/was the "FUCK FUCK FUCK" git clean vs git reset UX error: https://github.com/microsoft/

There are some warts, but it seems nice from afar. The biggest wart is/was the "FUCK FUCK FUCK" git clean vs git reset UX error: https://github.com/microsoft/vscode/issues/32405 https://github.com/microsoft/vscode/issues/32405 . This is a fantastic demonstration of why i exclusively use git from a command prompt -- i know what will happen and nobody's going to reinvent terms to put on buttons that just confuse me. In my life: - I'm committed to emacs for org-mode and LaTeX editing and daily use. - I paid for sublime so i will use it -- and multiple cursors everywhere is a boon for quick and dirty data munging. - I write serious python code in pycharm. - I write serious c# in full blown Visual Studio

bassman9000 8y ago
amen people look at me like I'm an old crazy dude because I don't use a git UI or eclipse, or intellij, or from sublime. Git already has plenty of quirks, adding another layer of unknown on top of it is a no-go
- freehunter 8y ago
  Which is weird because with all of its inconsistencies, git must have been designed with the idea that someone would build a sensible shell over top of it. I can't imagine Linus expected people to interact directly with git when he built it.
  - bassman9000 8y ago
    git has its problems, but it's a consistent, centralized (in the sense of origin/repo), well known set of problems. I use multiple IDEs/editors, and they all handle git differently. It doesn't make sense to learn yet another N sets of quirks.
    - Drdrdrq 8y ago
      > git has its problems, but it's a consistent, centralized (in the sense of origin/repo), well known set of problems. Consistent? Ha! Change branch: git checkout my-branch. Reset file to committed version: git checkout -- my-file. Git is many things, but consistent it is not. That said, I still use CLI precisely because I don't trust other software to make sensible abstractions on top of it, given that foundation is so inconsistent. Besides, those CI scripts only know git cli...
      - umanwizard 8y ago
        Consistent in time. Those warts haven't changed much in the 7 or 8 years that I've been using git.
      - bassman9000 8y ago
        > Consistent? Ha! Change branch: git checkout my-branch. Reset file to committed version: git checkout -- my-file. Git is many things, but consistent it is not. > well known set of problems that's precisely the well know set of problems. You learn them once, apply on every console. If each UI decides to overcome them differently, you end up with N+1 different behaviors. I'd rather have only one set if inconsistent commands, than 3. edit:formatting
  - bgruber 8y ago
    this is precisely the case: http://www.gelato.unsw.edu.au/archives/git/0504/0873.html http://www.gelato.unsw.edu.au/archives/git/0504/0873.html
    - voltagex_ 8y ago
      OT: that's a blast from the past - http://www.gelato.unsw.edu.au/ http://www.gelato.unsw.edu.au/
- emerongi 8y ago
  I've started using VSCode for git push/pull/branch and staging. This is what I use git for 99% of the time anyways and since they are simple commands, triggering them from VSCode is faster than falling back to CLI. Staging/diffing is especially convenient with VSCode. `git add -p` used to be my most-used command, but VSCode just makes the process easier.
  - gknoy 8y ago
    If you stage things often enough, `git add -u` might be enough. It's pretty much what I use all the time, aside from the few times I do `git add -up`.
- kstrauser 8y ago
  My most famous quote in my work Slack is: "git already has a luxurious client! it’s called git and has lots of shinies."
  - CuriouslyC 8y ago
    While I agree with this in most cases, visual merge is a huge deal.
    - freeone3000 8y ago
      git mergetool will spawn the mergetool of your choice, anything from kdiff3 to vimdiff.
- dagw 8y ago
  Heh. As an "old dude" I'd assume that anybody using git directly would be a "young dude" who's been using git all their programming life.
bdcravens 8y ago
I've had best results decoupling my tools, so I use a separate git client (in my case, Git Tower). You can also add things like database clients to VSC, but similarly I use Datagrip etc.
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.
matwood 8y ago
> This is a fantastic demonstration of why i exclusively use git from a command prompt -- i know what will happen and nobody's going to reinvent terms to put on buttons that just confuse me. This many times. I'll open SourceTree to view a large set of diffs or changes, but still drop back to the CLI to push/pull/rebase/commit/stash/etc... I know what git will do in those cases, and am a little wary of git UIs.
- bayindirh 8y ago
  Actually Eclipse's git UI is very practical. I use it whenever I'm developing somehting in Eclipse, however I still command line as much for other reasons. OTOH, I despise heavily modified bash/zsh/whatever profiles which makes the environment non-portable. Extreme eye-candy in the console makes stuff harder for devs/admins who logs in to thousands of servers.
21 8y ago
> I paid for sublime so i will use it -- and multiple cursors everywhere is a boon for quick and dirty data munging These days pretty much every serious editor has multiple cursors, including Visual Studio Code.
- zwieback 8y ago
  had to look up "multiple cursors" and it looks like it's the same as "column mode" which has been around in MS editors forever?
  - deleted 8y ago
    [deleted]
  - negativegate 8y ago
    It's not column mode in Visual Studio Code https://code.visualstudio.com/docs/editor/codebasics#_multiple-selections-multicursor https://code.visualstudio.com/docs/editor/codebasics#_multip...
    - zwieback 8y ago
      Indeed, I've been missing out!
  - pmarreck 8y ago
    dude. you have been missing out.
ddavis 8y ago
Since you're an Emacs user... just wanted to plug magit - it might make you change your mind about command-prompt-only git usage
- wry_discontent 8y ago
  I use Emacs mostly for magit.
Zaheer 8y ago
P.S. VSCode has multi-cursor as well: https://code.visualstudio.com/docs/getstarted/tips-and-tricks#_multi-cursor-selection https://code.visualstudio.com/docs/getstarted/tips-and-trick...
- markrages 8y ago
  and emacs of course. https://youtu.be/jNa3axo40qM https://youtu.be/jNa3axo40qM
_coveredInBees 8y ago
To each their own. I've used CLI git only for a decent amount of time but VSCode's git diff view is fantastic and effortless to use. Their interface for staging files and making commits is excellent and combined with the ease of viewing local changes, it makes it very easy to ensure that commit messages are well documented and accurate. Same goes for handling merge conflicts. I still use the CLI to push/pull/branch/merge, etc just to have total control, but staging files, viewing diffs and making commits are a lot more annoying in the CLI.
pmarreck 8y ago
> and multiple cursors everywhere is a boon for quick and dirty data munging. VSCode has this. Hold down Command on Macs (probably Ctrl on Windows/Linux) and click. You can also select "next similar word" with command-D so you can quickly change all instances of a word to another word.
- _coveredInBees 8y ago
  Ctrl+Shift+L will select all instances of the highlighted term in one shot. Ctrl+D , as you mentioned, is useful for progressively selecting the highlighted phrase within the file.
  - pmarreck 8y ago
    Awesome, TIL about Ctrl-Shift-L!
deleted 8y ago
[deleted]
starik36 8y ago
> fantastic demonstration of why i exclusively use git from a command prompt What's described in that github issue happened to me as well the first time I used git via Visual Studio. I normally don't do that, but something told me to make a zip of everything before using git in VS. So that saved me big time. Why in the world are the deletions not pointed to the Recycle Bin??? That's what it's there for.
- smbullet 8y ago
  Agreed, it's sort of surreal that nobody in any of the issue threads admitted that was a good solution.
  - overgard 8y ago
    It’s not a good solution at all; it makes no sense in the context of source control because the repository IS the undo button, and copying discarded changes to the recycle bin would just add a lot of incoherent duplication into the recycle bin for no reason. Not to mention that’s not how git works, so it’d have to be added as a git extension, and you’d end up with people who actually know how their source control tools work feeling confused and annoyed that their editor is changing how their familiar tools work. I mean, if you point software you don’t understand at work that’s not backed up you shouldn’t be shocked if it does something you don’t like
- Sacho 8y ago
  The deletions are made through git, and windows git does not use the recycle bin, presumably because it's a linux-first tool
  - jhasse 8y ago
    It doesn't use the recycle bin on Linux either.
dlhavema 8y ago
I do command line git as well because I am bouncing between IDEs and dont want to learn the differences in little features of each IDEs source control ui.
anilakar 8y ago
> I paid for sublime so i will use it I purchased Sublime when it was the least bad editor out there, but finally realized that I was suffering from the sunk cost fallacy. I still consider it the worst software purchase I've ever made, and it's also why I'm reluctant to pay a single buck for software nowadays.
- thecopy 8y ago
  Why do you think Sublime Text is the worst software you have purchased? I use it every day as my main text editor and i am very satisfied.
  - anilakar 8y ago
    See the reply to the sibling post. In any case, what works for you might not work for other people. We're also talking about four–five years old issues here.
- giancarlostoro 8y ago
  I mean I use VS Code a lot more often, and PyCharm / JetBrains IDES moreso than I do Sublime Text but I wouldn't say it's the worst purchase. I bought a text editor that's got out of the box syntax highlighting for most languages and decent enough linting plugins to catch some of the syntax errors I may be about to miss. I only wish Sublime Text were able to (out of the box) mount / SSH into any server like emacs does (using TRAMP). I'm finding myself using VIM lately mostly because it's a step up from nano which uses tabs, not sure how to tell it how to space things, nano is perfect for Go I suppose. I have to figure out how to configure VIM for spacing things properly though, but I mostly install Sublime Text on VM's I write code in.
  - anilakar 8y ago
    I originally had two reasons why I bought Sublime. The primary one was that it felt like Vim with everything configured out of the box. Another reason was that ST2 had long outstanding bugs that were already fixed in the ST3 development version, which was made available to paying customers only, and it felt like a good idea to support the development. Then came 2014 and it started to look like the Sublime developer had taken a hiatus. The timing was really bad as ST2 still had showstopper issues (for me) that were fixed in ST3, which in turn had another bunch of unfixed bugs. Meanwhile Atom was released and it got its bug fixes and new features regularly, even though it was and still is really slow. I had to choose between two borderline unusable and one functioning but heavy editor. With a heavy heart I had to abandon an editor that I had valued at 70 dollars, which at that time was also the largest sum I had ever paid for software. As soon as VS Code started to gain traction, I made the switch. For some reason it felt and still feels much snappier, even though both Atom and it are built on Electron and have approximately the same features. When not writing code or LaTeX documents, I'm editor and OS agnostic. Often you just have to make do with whatever an esoteric system offers.
sireat 8y ago
I managed to commit node_modules folder to github using VS Code git integration. Luckily it was on a smaller test project. My fault but there was a UI failure. All I did was press Commit which apparently decided to stage and commit everything under the root folder. It didn't do this in other projects so who knows what was different. This is how credential files must get committed to github every day. If VS Code is going to be smart about so many other things, then there should be some sort of warning for major code affecting changes. You are about to push 5000 files to master repo inluding some that appear to be widely used libraries, are you sure that is what you want ?
- GordonS 8y ago
  > All I did was press Commit which apparently decided to stage and commit everything under the root folder If you don't have anything staged and hit Commit, it will show a prompt asking if you want to commit everything that's been changed. It sounds like you hit 'yes' on this prompt by mistake.
rjbwork 8y ago
I use TortoiseHg for Hg. Source Tree for git (though I honestly don't like it very much, and often use hg-git to just work with git from TortoiseHg). Sublime for text editing; and agreed on the multiple cursors and great regexing - fantastic for quick and dirty munging indeed. I use VS for writing C#, creating SQL databases, and a myriad of other functions that would take too long to get into. LinqPad for quick experiments or writing up some quick scripts I need to run rarely.
omaranto 8y ago
Since you mention both using git directly from the command line and Emacs, have you tried magit?
SomeHacker44 8y ago
I am much the same. I have stickers for IntelliJ (as a stand in for all JetBrains IDEs), Emacs and Vim on my laptop because each has a different use case and preferred language. I even have Atom, Sublime and others installed and use them on rare occasions when they have plugins that are useful for a task at hand. I also exclusively use the command line for source control (of which I use at least four, but mostly git and hg). I just do not trust IDEs to do the right thing, although JetBrains does get close (but my colleague devs hate the properly pruned .idea in the repos).
bishala 8y ago
multi cursor is pretty much a basic feature in all modern text editors these days.

bassman9000 8y ago

amen people look at me like I'm an old crazy dude because I don't use a git UI or eclipse, or intellij, or from sublime. Git already has plenty of quirks, adding another layer of unknown on top of it is a no-go

freehunter 8y ago
Which is weird because with all of its inconsistencies, git must have been designed with the idea that someone would build a sensible shell over top of it. I can't imagine Linus expected people to interact directly with git when he built it.
- bassman9000 8y ago
  git has its problems, but it's a consistent, centralized (in the sense of origin/repo), well known set of problems. I use multiple IDEs/editors, and they all handle git differently. It doesn't make sense to learn yet another N sets of quirks.
  - Drdrdrq 8y ago
    > git has its problems, but it's a consistent, centralized (in the sense of origin/repo), well known set of problems. Consistent? Ha! Change branch: git checkout my-branch. Reset file to committed version: git checkout -- my-file. Git is many things, but consistent it is not. That said, I still use CLI precisely because I don't trust other software to make sensible abstractions on top of it, given that foundation is so inconsistent. Besides, those CI scripts only know git cli...
    - umanwizard 8y ago
      Consistent in time. Those warts haven't changed much in the 7 or 8 years that I've been using git.
    - bassman9000 8y ago
      > Consistent? Ha! Change branch: git checkout my-branch. Reset file to committed version: git checkout -- my-file. Git is many things, but consistent it is not. > well known set of problems that's precisely the well know set of problems. You learn them once, apply on every console. If each UI decides to overcome them differently, you end up with N+1 different behaviors. I'd rather have only one set if inconsistent commands, than 3. edit:formatting
- bgruber 8y ago
  this is precisely the case: http://www.gelato.unsw.edu.au/archives/git/0504/0873.html http://www.gelato.unsw.edu.au/archives/git/0504/0873.html
  - voltagex_ 8y ago
    OT: that's a blast from the past - http://www.gelato.unsw.edu.au/ http://www.gelato.unsw.edu.au/
emerongi 8y ago
I've started using VSCode for git push/pull/branch and staging. This is what I use git for 99% of the time anyways and since they are simple commands, triggering them from VSCode is faster than falling back to CLI. Staging/diffing is especially convenient with VSCode. `git add -p` used to be my most-used command, but VSCode just makes the process easier.
- gknoy 8y ago
  If you stage things often enough, `git add -u` might be enough. It's pretty much what I use all the time, aside from the few times I do `git add -up`.
kstrauser 8y ago
My most famous quote in my work Slack is: "git already has a luxurious client! it’s called git and has lots of shinies."
- CuriouslyC 8y ago
  While I agree with this in most cases, visual merge is a huge deal.
  - freeone3000 8y ago
    git mergetool will spawn the mergetool of your choice, anything from kdiff3 to vimdiff.
dagw 8y ago
Heh. As an "old dude" I'd assume that anybody using git directly would be a "young dude" who's been using git all their programming life.

bdcravens 8y ago

I've had best results decoupling my tools, so I use a separate git client (in my case, Git Tower). You can also add things like database clients to VSC, but similarly I use Datagrip etc.

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.

matwood 8y ago

> This is a fantastic demonstration of why i exclusively use git from a command prompt -- i know what will happen and nobody's going to reinvent terms to put on buttons that just confuse me. This many times. I'll open SourceTree to view a large set of diffs or changes, but still drop back to the CLI to push/pull/rebase/commit/stash/etc... I know what git will do in those cases, and am a little wary of git UIs.

bayindirh 8y ago
Actually Eclipse's git UI is very practical. I use it whenever I'm developing somehting in Eclipse, however I still command line as much for other reasons. OTOH, I despise heavily modified bash/zsh/whatever profiles which makes the environment non-portable. Extreme eye-candy in the console makes stuff harder for devs/admins who logs in to thousands of servers.

21 8y ago

> I paid for sublime so i will use it -- and multiple cursors everywhere is a boon for quick and dirty data munging These days pretty much every serious editor has multiple cursors, including Visual Studio Code.

zwieback 8y ago
had to look up "multiple cursors" and it looks like it's the same as "column mode" which has been around in MS editors forever?
- deleted 8y ago
  [deleted]
- negativegate 8y ago
  It's not column mode in Visual Studio Code https://code.visualstudio.com/docs/editor/codebasics#_multiple-selections-multicursor https://code.visualstudio.com/docs/editor/codebasics#_multip...
  - zwieback 8y ago
    Indeed, I've been missing out!
- pmarreck 8y ago
  dude. you have been missing out.

ddavis 8y ago

Since you're an Emacs user... just wanted to plug magit - it might make you change your mind about command-prompt-only git usage

wry_discontent 8y ago
I use Emacs mostly for magit.

Zaheer 8y ago

P.S. VSCode has multi-cursor as well: https://code.visualstudio.com/docs/getstarted/tips-and-tricks#_multi-cursor-selection https://code.visualstudio.com/docs/getstarted/tips-and-trick...

markrages 8y ago
and emacs of course. https://youtu.be/jNa3axo40qM https://youtu.be/jNa3axo40qM

_coveredInBees 8y ago

To each their own. I've used CLI git only for a decent amount of time but VSCode's git diff view is fantastic and effortless to use. Their interface for staging files and making commits is excellent and combined with the ease of viewing local changes, it makes it very easy to ensure that commit messages are well documented and accurate. Same goes for handling merge conflicts. I still use the CLI to push/pull/branch/merge, etc just to have total control, but staging files, viewing diffs and making commits are a lot more annoying in the CLI.

pmarreck 8y ago

> and multiple cursors everywhere is a boon for quick and dirty data munging. VSCode has this. Hold down Command on Macs (probably Ctrl on Windows/Linux) and click. You can also select "next similar word" with command-D so you can quickly change all instances of a word to another word.

_coveredInBees 8y ago
Ctrl+Shift+L will select all instances of the highlighted term in one shot. Ctrl+D , as you mentioned, is useful for progressively selecting the highlighted phrase within the file.
- pmarreck 8y ago
  Awesome, TIL about Ctrl-Shift-L!

deleted 8y ago

[deleted]

starik36 8y ago

> fantastic demonstration of why i exclusively use git from a command prompt What's described in that github issue happened to me as well the first time I used git via Visual Studio. I normally don't do that, but something told me to make a zip of everything before using git in VS. So that saved me big time. Why in the world are the deletions not pointed to the Recycle Bin??? That's what it's there for.

smbullet 8y ago
Agreed, it's sort of surreal that nobody in any of the issue threads admitted that was a good solution.
- overgard 8y ago
  It’s not a good solution at all; it makes no sense in the context of source control because the repository IS the undo button, and copying discarded changes to the recycle bin would just add a lot of incoherent duplication into the recycle bin for no reason. Not to mention that’s not how git works, so it’d have to be added as a git extension, and you’d end up with people who actually know how their source control tools work feeling confused and annoyed that their editor is changing how their familiar tools work. I mean, if you point software you don’t understand at work that’s not backed up you shouldn’t be shocked if it does something you don’t like
Sacho 8y ago
The deletions are made through git, and windows git does not use the recycle bin, presumably because it's a linux-first tool
- jhasse 8y ago
  It doesn't use the recycle bin on Linux either.

dlhavema 8y ago

I do command line git as well because I am bouncing between IDEs and dont want to learn the differences in little features of each IDEs source control ui.

anilakar 8y ago

> I paid for sublime so i will use it I purchased Sublime when it was the least bad editor out there, but finally realized that I was suffering from the sunk cost fallacy. I still consider it the worst software purchase I've ever made, and it's also why I'm reluctant to pay a single buck for software nowadays.

thecopy 8y ago
Why do you think Sublime Text is the worst software you have purchased? I use it every day as my main text editor and i am very satisfied.
- anilakar 8y ago
  See the reply to the sibling post. In any case, what works for you might not work for other people. We're also talking about four–five years old issues here.
giancarlostoro 8y ago
I mean I use VS Code a lot more often, and PyCharm / JetBrains IDES moreso than I do Sublime Text but I wouldn't say it's the worst purchase. I bought a text editor that's got out of the box syntax highlighting for most languages and decent enough linting plugins to catch some of the syntax errors I may be about to miss. I only wish Sublime Text were able to (out of the box) mount / SSH into any server like emacs does (using TRAMP). I'm finding myself using VIM lately mostly because it's a step up from nano which uses tabs, not sure how to tell it how to space things, nano is perfect for Go I suppose. I have to figure out how to configure VIM for spacing things properly though, but I mostly install Sublime Text on VM's I write code in.
- anilakar 8y ago
  I originally had two reasons why I bought Sublime. The primary one was that it felt like Vim with everything configured out of the box. Another reason was that ST2 had long outstanding bugs that were already fixed in the ST3 development version, which was made available to paying customers only, and it felt like a good idea to support the development. Then came 2014 and it started to look like the Sublime developer had taken a hiatus. The timing was really bad as ST2 still had showstopper issues (for me) that were fixed in ST3, which in turn had another bunch of unfixed bugs. Meanwhile Atom was released and it got its bug fixes and new features regularly, even though it was and still is really slow. I had to choose between two borderline unusable and one functioning but heavy editor. With a heavy heart I had to abandon an editor that I had valued at 70 dollars, which at that time was also the largest sum I had ever paid for software. As soon as VS Code started to gain traction, I made the switch. For some reason it felt and still feels much snappier, even though both Atom and it are built on Electron and have approximately the same features. When not writing code or LaTeX documents, I'm editor and OS agnostic. Often you just have to make do with whatever an esoteric system offers.

sireat 8y ago

I managed to commit node_modules folder to github using VS Code git integration. Luckily it was on a smaller test project. My fault but there was a UI failure. All I did was press Commit which apparently decided to stage and commit everything under the root folder. It didn't do this in other projects so who knows what was different. This is how credential files must get committed to github every day. If VS Code is going to be smart about so many other things, then there should be some sort of warning for major code affecting changes. You are about to push 5000 files to master repo inluding some that appear to be widely used libraries, are you sure that is what you want ?

GordonS 8y ago
> All I did was press Commit which apparently decided to stage and commit everything under the root folder If you don't have anything staged and hit Commit, it will show a prompt asking if you want to commit everything that's been changed. It sounds like you hit 'yes' on this prompt by mistake.

rjbwork 8y ago

I use TortoiseHg for Hg. Source Tree for git (though I honestly don't like it very much, and often use hg-git to just work with git from TortoiseHg). Sublime for text editing; and agreed on the multiple cursors and great regexing - fantastic for quick and dirty munging indeed. I use VS for writing C#, creating SQL databases, and a myriad of other functions that would take too long to get into. LinqPad for quick experiments or writing up some quick scripts I need to run rarely.

omaranto 8y ago

Since you mention both using git directly from the command line and Emacs, have you tried magit?

SomeHacker44 8y ago

I am much the same. I have stickers for IntelliJ (as a stand in for all JetBrains IDEs), Emacs and Vim on my laptop because each has a different use case and preferred language. I even have Atom, Sublime and others installed and use them on rare occasions when they have plugins that are useful for a task at hand. I also exclusively use the command line for source control (of which I use at least four, but mostly git and hg). I just do not trust IDEs to do the right thing, although JetBrains does get close (but my colleague devs hate the properly pruned .idea in the repos).

bishala 8y ago

multi cursor is pretty much a basic feature in all modern text editors these days.