this post was submitted on 20 Nov 2024
850 points (97.4% liked)

Programmer Humor

19623 readers
214 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] MajorasMaskForever@lemmy.world 17 points 1 day ago (4 children)

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)

[–] Knock_Knock_Lemmy_In@lemmy.world 11 points 1 day ago (3 children)

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

[–] ulterno@programming.dev 2 points 1 day ago* (last edited 1 day 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.

[–] Antiproton@programming.dev 11 points 1 day ago (1 children)

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

[–] MajorHavoc@programming.dev 4 points 1 day 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.

[–] MajorasMaskForever@lemmy.world 2 points 1 day ago (1 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@programming.dev 1 points 1 day 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.

[–] _____@lemm.ee 3 points 1 day 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

[–] dave@feddit.uk 5 points 1 day 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.

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