As much as I understand the ease of use of git lens, I strongly disagree with your title statement. Or, more precisely, I think depending on an IDE for using git is dangerous.
Knowing your way around git in a cli is very important: connecting to a remote server? Writing or debugging a CD pipeline? Needing to do something there is no button for? Or simply wanting to quickly do an operation without having to load a bloated IDE? (yes, vs code is fast at the beginning, but add the 100+ plug-ins you need - according to posts here, and suddenly...)
So my advice is: work with the cli first. It may be painful at first, but will become a second language at some point. Don't give up. Only once you are perfectly fluent with the cli, then switch to lazygit, git lens, or another tool.
Git is a the root of any programming activity, so it should be deeply understood and there is no better way than the cli for this. It also comes in handy in job interviews ;)
PS: coming from a full stack background, there is to me no better interface than a terminal.
You shouldn't do that anyway. Per-line staging is reasonably simple (git add -p), but the real question is: why would you want to do that in the first place?
Normally, you'd want to commit an entire working changeset.
When you have something small and contained... absolutely.
But when you start touching multiple things at once (and it can be as little as fixing a typo).
Then I do prefer on making an atomic commit, even if only changing a single letter.
More than that, multiple times I find myself working a whole feature that I can commit block by block with a more meaningful message than if I were to squash all of them in a single commit.
Totally agree. (Except for making line by line staging, which is so much easier in the IDE)
But for me, more than just being "fast".
I read, edit and refator the code multiple times before even thinking on commiting it.
So, when I go to commit, the "ritual" of going file by file or even line by line and making each commit is another pass through the code that I would not do if I just blaze through it adding everything and using some macro to add, commit and push everything.
In this regard, it's not about speed, but being thoughtful of each step of what you're doing.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As much as I understand the ease of use of git lens, I strongly disagree with your title statement. Or, more precisely, I think depending on an IDE for using git is dangerous.
Knowing your way around git in a cli is very important: connecting to a remote server? Writing or debugging a CD pipeline? Needing to do something there is no button for? Or simply wanting to quickly do an operation without having to load a bloated IDE? (yes, vs code is fast at the beginning, but add the 100+ plug-ins you need - according to posts here, and suddenly...)
So my advice is: work with the cli first. It may be painful at first, but will become a second language at some point. Don't give up. Only once you are perfectly fluent with the cli, then switch to lazygit, git lens, or another tool.
Git is a the root of any programming activity, so it should be deeply understood and there is no better way than the cli for this. It also comes in handy in job interviews ;)
PS: coming from a full stack background, there is to me no better interface than a terminal.
Absolutely agree with this answer. Depending on an IDE to do your stuff is probably the worst "decision" you can make.
Also people tend to think that they'll be faster using some GUI, that's because they don't know how to use the CLI properly.
While I agree with most.
I don't think you can commit it line by line, all while possibly editing stuff, even without saving, in between.
You shouldn't do that anyway. Per-line staging is reasonably simple (
git add -p), but the real question is: why would you want to do that in the first place?Normally, you'd want to commit an entire working changeset.
When you have something small and contained... absolutely.
But when you start touching multiple things at once (and it can be as little as fixing a typo).
Then I do prefer on making an atomic commit, even if only changing a single letter.
More than that, multiple times I find myself working a whole feature that I can commit block by block with a more meaningful message than if I were to squash all of them in a single commit.
Totally agree. (Except for making line by line staging, which is so much easier in the IDE)
But for me, more than just being "fast".
I read, edit and refator the code multiple times before even thinking on commiting it.
So, when I go to commit, the "ritual" of going file by file or even line by line and making each commit is another pass through the code that I would not do if I just blaze through it adding everything and using some macro to add, commit and push everything.
In this regard, it's not about speed, but being thoughtful of each step of what you're doing.