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)

[–] Antiproton 14 points 1 month ago (1 children)

The difference in speed is familiarity, not some inherent efficiency gain by typing commands into the cli.

[–] MajorHavoc 7 points 1 month ago (1 children)

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.

[–] [email protected] 4 points 1 month ago (2 children)

The real metric is dollars per second of destroyed hardware ;)

I once watched an engineer blow up a $200k prototype with a terminal alias.

[–] MajorHavoc 2 points 1 month ago

That's impressive. I'm glad I don't have any story to match that. Hopefully they find it hilarious now. Probably no fun at the time.

[–] [email protected] 1 points 4 weeks ago

I once watched an engineer blow up a $200k prototype with a terminal alias.

I once worked with someone who accidentally deleted our company's entire Git server. We had backups thankfully, but they were nearly a week old.

Thank the gods for git being distributed, so the vast majority of the work from the last week was recoverable because it was on someone's machine locally.

[–] [email protected] 14 points 1 month ago (3 children)

If I want to commit a selection of files, but not others, then I'm clicking boxes not typing filenames.

[–] [email protected] 6 points 1 month ago

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

[–] PoolloverNathan 4 points 1 month ago

git add -p

[–] ulterno 2 points 1 month ago* (last edited 1 month ago)

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.

[–] [email protected] 7 points 1 month ago (1 children)

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.

[–] [email protected] 3 points 1 month ago

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

[–] [email protected] 4 points 1 month ago (1 children)

Currently using Tortoise and SVN for the first time at my job, and I hate it.

[–] MajorHavoc 4 points 1 month ago* (last edited 1 month ago)

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 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.

[–] [email protected] 3 points 1 month ago

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

[–] BatmanAoD 1 points 4 weeks ago

Tortoise git is probably what convinced me to just use the CLI for everything back in the day. Tortoise SVN is basically 1:1 with the SVN CLI (as far as I could tell, at least); Tortoise Git was...not.

Maybe other git UIs are better. I hope so! Maybe even Tortoise has gotten better. But it was not good back then. (This was around 2013.)