Every time I mentor a dev on using git they insist so much on using some GUI. Even ones who are “proficient” take way longer to do any action than I can with cli. I had one dev who came from SVN land try and convince me that TortoiseGit was the only way to go
I died a little that day, and I never won her over to command line despite her coming to me kinda regularly to un-fuck her repository (still one of the best engineers I ever worked with and I honestly miss her… Just not her source control antics)
That is the one use case I’ve seen where a gui is absolutely faster.
In my line of work, I primarily work on embedded systems or process automation so any new files in the repo directory either need to be added for tracking or to the ignore file. I’m not saying it will never happen, but at least in my experience it happens so rarely that I always try to teach command line when possible
Did you not know?
You can simply select all files you want to commit, in the File Manager, Ctrl+C, then paste in the terminal and it will automatically add all those file names (full paths) separated with spaces at the cursor. At least in KDE: Dolphin -> zsh + Konsole it does.
And sure, it might look like 2 extra steps, but you will still be clicking around a lot in case of a GUI anyway.
I tend to just type partial filenames and use tab completions, which are also pretty configurable. And the only dissatisfaction I have rn, is that I don’t have zsh module for completions with pascal case and snake case.
But I defy anyone’s mouse-foo to come anywhere near the speed of my typing speed and alias list.
Even someone mastering GUI keyboard shortcuts isn’t going to be able to match, because my terminal is optimized beyond what is possible in a more graphical app.
What I’m trying to say is that no one can introduce a thoughtless mistake into production code as quickly as I can.
So I’m normally a command line fan and have used git there. But I’m also using sublimerge and honestly I find it fantastic for untangling a bunch of changes that need to be in several commits; being able to quickly scroll through all the changed files, expand & collapse the diffs, select files, hunks, and lines directly in the gui for staging, etc. I can’t see that being any faster / easier on the command line.
Heh, I guess this shows my corporate software dev experience. Whenever I’ve taught git workflows it was always paired with a work ticketing system where any changes you were making were ideally all one single set of changes. If you need a feature or bug fix someone else was doing that was being done on another branch which you could pull into your code early and for tracking purposes we always made sure the other person merged into main first. The only time I’ve seen per line manipulation with git was when someone made a ton of changes in a file and wanted to revert a handful of lines.
Everything else you mentioned I’ve had a web git host like gitlab or bitbucket for, but I kinda put that more into peer review workflow than git itself
that’s exactly why I’m saying this. I know from experience helping other devs with git issues it’s always because they’re using a GUI alternative to the CLI and they’re clicking on things they don’t understand
Using SVN was like a having a thoughtful professional assistant who ignored half of what I said and occasionally threw medium sized objects at my head without warning.
You’re allowed to mock the whole organization mercilessly until they upgrade to git. Git is completely free, and the available upgrade tools are lossless. Also git actually works perfectly fine when naively treated like SVN.
Source: I used git naively like SVN for awhile after (flawlessly) upgrading a huge number of repositories.
Every time I mentor a dev on using git they insist so much on using some GUI. Even ones who are “proficient” take way longer to do any action than I can with cli. I had one dev who came from SVN land try and convince me that TortoiseGit was the only way to go
I died a little that day, and I never won her over to command line despite her coming to me kinda regularly to un-fuck her repository (still one of the best engineers I ever worked with and I honestly miss her… Just not her source control antics)
If I want to commit a selection of files, but not others, then I’m clicking boxes not typing filenames.
That is the one use case I’ve seen where a gui is absolutely faster.
In my line of work, I primarily work on embedded systems or process automation so any new files in the repo directory either need to be added for tracking or to the ignore file. I’m not saying it will never happen, but at least in my experience it happens so rarely that I always try to teach command line when possible
git add -pDid you not know?
You can simply select all files you want to commit, in the File Manager, Ctrl+C, then paste in the terminal and it will automatically add all those file names (full paths) separated with spaces at the cursor. At least in KDE: Dolphin ->
zsh+ Konsole it does.And sure, it might look like 2 extra steps, but you will still be clicking around a lot in case of a GUI anyway.
I tend to just type partial filenames and use tab completions, which are also pretty configurable. And the only dissatisfaction I have rn, is that I don’t have
zshmodule for completions with pascal case and snake case.The difference in speed is familiarity, not some inherent efficiency gain by typing commands into the cli.
You’re 100% right.
But I defy anyone’s mouse-foo to come anywhere near the speed of my typing speed and alias list.
Even someone mastering GUI keyboard shortcuts isn’t going to be able to match, because my terminal is optimized beyond what is possible in a more graphical app.
What I’m trying to say is that no one can introduce a thoughtless mistake into production code as quickly as I can.
The real metric is dollars per second of destroyed hardware ;)
I once watched an engineer blow up a $200k prototype with a terminal alias.
So I’m normally a command line fan and have used git there. But I’m also using sublimerge and honestly I find it fantastic for untangling a bunch of changes that need to be in several commits; being able to quickly scroll through all the changed files, expand & collapse the diffs, select files, hunks, and lines directly in the gui for staging, etc. I can’t see that being any faster / easier on the command line.
Heh, I guess this shows my corporate software dev experience. Whenever I’ve taught git workflows it was always paired with a work ticketing system where any changes you were making were ideally all one single set of changes. If you need a feature or bug fix someone else was doing that was being done on another branch which you could pull into your code early and for tracking purposes we always made sure the other person merged into main first. The only time I’ve seen per line manipulation with git was when someone made a ton of changes in a file and wanted to revert a handful of lines.
Everything else you mentioned I’ve had a web git host like gitlab or bitbucket for, but I kinda put that more into peer review workflow than git itself
that’s exactly why I’m saying this. I know from experience helping other devs with git issues it’s always because they’re using a GUI alternative to the CLI and they’re clicking on things they don’t understand
Currently using Tortoise and SVN for the first time at my job, and I hate it.
Welcome to the brotherhood. Haha. Ow.
Using SVN was like a having a thoughtful professional assistant who ignored half of what I said and occasionally threw medium sized objects at my head without warning.
You’re allowed to mock the whole organization mercilessly until they upgrade to git. Git is completely free, and the available upgrade tools are lossless. Also
gitactually works perfectly fine when naively treated like SVN.Source: I used git naively like SVN for awhile after (flawlessly) upgrading a huge number of repositories.