5 ms·

Forget the CLI. VSCode implements a ton of git features as commands, which can be bound to any keybindings. For me this is way faster than CLI, as I don’t even

by jakear 4y ago

Forget the CLI. VSCode implements a ton of git features as commands, which can be bound to any keybindings. For me this is way faster than CLI, as I don’t even need to leave my text editor - I have it set up chorded, so AltG followed by P,U,C,Y, will push (actually sync), pull, commit, undo, respectively. Two keystrokes beats any CLI interaction I’ve seen. (Disclaimer used to make VSCode)

stevage 4y ago
I used to use Gitsavvy in Sublime, and honestly it was much, much better than what VSCode offers so far.
zabzonk 4y ago
because doing a commit with one keystroke is a good thing? i think it isn't - i like to consider things, rather than program like a hyperactive cockroach
- jakear 4y ago
  You still gotta type the message.
  - gen220 4y ago
    I think the original poster was referring to staging the commit as their "thinking" step, not composing the message. Personally, my workflow is to make many changes, then use `add -p` and `commit` to create a series of small commits. While staging, you might decide that you don't want to commit some bit of code and `restore -p` to toss it away. I think your workflow would work well if you see commits as "development checkpoints" rather than semantic patches. It's not an invalid workflow, just a different one. I'm sure you could configure VSC to be analogously ergonomic for any git workflow. But people who are comfortable with git and their shell of choice tend to develop comfortable workflows in the terminal as well.
    - boardwaalk 4y ago
      For what it's worth, you can do similar to "add -p" in VSC by using "Next Change" to scroll through a file in the diff view and adding hunks with individually with "Stage Selected Ranges". It's a little slower than "add -p" but serviceable. Having editable diff in the diff view is really nice though.
- rgoulter 4y ago
  Taking time to consider things is good; but that doesn't mean you're better off with slow tools. If developing has some loop like "consider -> implement -> evaluate", then the quicker you can implement it, the more budget you have for considering the problem.
galaxyLogic 4y ago
I agree why should I switch from editor to terminal to do a commit. In WebStorm it is Ctrl-K plus adding the commit-message.
djur 4y ago
Most people's objections to git ergonomics is not that the commands are slow to type. VS Code exposes the exact same operations on the underlying repository as the CLI, and it's those operations that critics say are hard to understand and cumbersome to use.
- jakear 4y ago
  The parent said: > This looks incredible. A simple command to uncommit or unamend makes you further realise what a disaster the Git CLI is. I said that simple command already exists in VS Code. Yes it can be done via CLI, but not as simply as in VS Code. Not sure what your claim is.
  - djur 4y ago
    What is the unamend command in VS Code?
_ZeD_ 4y ago
dude, vscode git interface is ... not really good. I really continue to keep a copy of eclipse around just to use the egit client. That is a good UI ihmo
- jakear 4y ago
  I'm talking about the available commands, the UI is purposefully minimal.

by jakear 4y ago

stevage 4y ago

I used to use Gitsavvy in Sublime, and honestly it was much, much better than what VSCode offers so far.

zabzonk 4y ago

because doing a commit with one keystroke is a good thing? i think it isn't - i like to consider things, rather than program like a hyperactive cockroach

jakear 4y ago
You still gotta type the message.
- gen220 4y ago
  I think the original poster was referring to staging the commit as their "thinking" step, not composing the message. Personally, my workflow is to make many changes, then use `add -p` and `commit` to create a series of small commits. While staging, you might decide that you don't want to commit some bit of code and `restore -p` to toss it away. I think your workflow would work well if you see commits as "development checkpoints" rather than semantic patches. It's not an invalid workflow, just a different one. I'm sure you could configure VSC to be analogously ergonomic for any git workflow. But people who are comfortable with git and their shell of choice tend to develop comfortable workflows in the terminal as well.
  - boardwaalk 4y ago
    For what it's worth, you can do similar to "add -p" in VSC by using "Next Change" to scroll through a file in the diff view and adding hunks with individually with "Stage Selected Ranges". It's a little slower than "add -p" but serviceable. Having editable diff in the diff view is really nice though.
rgoulter 4y ago
Taking time to consider things is good; but that doesn't mean you're better off with slow tools. If developing has some loop like "consider -> implement -> evaluate", then the quicker you can implement it, the more budget you have for considering the problem.

galaxyLogic 4y ago

I agree why should I switch from editor to terminal to do a commit. In WebStorm it is Ctrl-K plus adding the commit-message.

djur 4y ago

Most people's objections to git ergonomics is not that the commands are slow to type. VS Code exposes the exact same operations on the underlying repository as the CLI, and it's those operations that critics say are hard to understand and cumbersome to use.

jakear 4y ago
The parent said: > This looks incredible. A simple command to uncommit or unamend makes you further realise what a disaster the Git CLI is. I said that simple command already exists in VS Code. Yes it can be done via CLI, but not as simply as in VS Code. Not sure what your claim is.
- djur 4y ago
  What is the unamend command in VS Code?

_ZeD_ 4y ago

dude, vscode git interface is ... not really good. I really continue to keep a copy of eclipse around just to use the egit client. That is a good UI ihmo

jakear 4y ago
I'm talking about the available commands, the UI is purposefully minimal.