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

Programmer Humor

19623 readers
2207 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
top 50 comments
sorted by: hot top controversial new old
[–] kamen@lemmy.world 10 points 2 hours ago

That has the same energy as complaining that a file manager has "Delete" in the context menu.

[–] ICastFist@programming.dev 2 points 1 hour ago

Same account that complained about the christmas santa hat

[–] kamen@lemmy.world 1 points 44 minutes ago* (last edited 40 minutes ago)

I agree with the "learn the CLI", but to newcomers I'll also suggest to look at the IDE/editor's output channel - if there's GUI for Git, there are also most likely logs for what's happening under the hood - even if a little noisy, it can be a good learning resource. And of course if you're learning and unsure of what's happening (with the CLI or through a GUI), do so in a non-destructive manner (by having proper backups).

[–] AusatKeyboardPremi@lemmy.world 14 points 3 hours ago* (last edited 2 hours ago) (1 children)

I always found Git GUIs, especially the ones built into IDEs, to be more confusing and clunkier than working with Git on a terminal. It often feels like unlearning what one knows about Git, and relearning it the way that specific GUI demands.

Heck, I am going through the aforementioned feeling as I force myself to use Magit on Emacs. It just does not feel intuitive. But I will not give up until I have made an honest and full attempt.

The only sensible Git GUI I ever used is Sublime Merge[0], after a coworker praised it immensely. Even that is reserved for the rarest of the rare times when the changes in the workspace gets unwieldy and unruly. For every other instance: Git CLI on a terminal.

[0] https://www.sublimemerge.com/

E: typo, and link to mentioned GUI.

[–] BehindTheBarrier@programming.dev 2 points 1 hour ago (1 children)

How do you view diffs and merges when you say you don't use git GUIs? External tool or terminal/command line?

I use Jetbrains IDEs and most of my life has been IDE based git interaction. And I honestly love it, easy access to see my diffs, the most common commit, push and stage(or shelve as Jetbrains does it, which is better than visual studio). Hassle free and available beats writing anything to me.

[–] AusatKeyboardPremi@lemmy.world 2 points 58 minutes ago

How do you view diffs and merges when you say you don't use git GUIs? External tool or terminal/command line?

Terminal.

I use Jetbrains IDEs and most of my life has been IDE based git interaction. And I honestly love it, easy access to see my diffs, the most common commit, push and stage(or shelve as Jetbrains does it, which is better than visual studio). Hassle free and available beats writing anything to me.

Perhaps, it is a mix of learned behaviour and cognitive fixation, as I started out my development journey predominantly using a terminal, that I cannot fathom Git GUI being hassle free.

Nice to read a different perspective on such a fundamental thing that I take for granted while working. Thank you for sharing it.

[–] Michal@programming.dev 2 points 2 hours ago (1 children)

If the files were already staged then git should have blobs in the git folder, so they should be recoverable.

[–] marcos@lemmy.world 6 points 1 hour ago (1 children)

Looks like they weren't staged. He clicked on the staging option, it showed it would stage thousands of files, he said "hey I should fix my .gitignore" and clicked on what looked like either a "don't stage" or a "forget" button, and it was a "checkout --force" button.

The most impressive thing is all the people doubling down on the idea that a "checkout --force" button in a main interaction screen is a great idea, there's nothing wrong with the software, and the user is a moron.

[–] JohnEdwa@sopuli.xyz 1 points 46 minutes ago* (last edited 45 minutes ago)

"discard changes" button - the 5000 "new file created" changes, specifically.

[–] RobotZap10000@feddit.nl 46 points 5 hours ago (2 children)

5000 files

0 backups

Someone's got their priorities mixed up.

[–] TheNSFWConnoisseur@lemmynsfw.com 14 points 2 hours ago

having 5000 backups of 0 files is also kinda pointless.

[–] QuazarOmega@lemy.lol 7 points 4 hours ago

You have to lose it all to know what matters (speaking from experience 😭)

[–] computerscientistII@lemm.ee 20 points 4 hours ago

No backup, no sympathy.

[–] AnUnusualRelic@lemmy.world 4 points 3 hours ago* (last edited 3 hours ago) (1 children)

Looks like windows should come with a dictionary.

"Huh, discard, I wonder what that does. Let's try it on all my work from the last six months"

Idiots gonna idiot...

[–] Forbo@lemmy.ml 8 points 2 hours ago (1 children)

Problem is, there's an entire generation of users that have gotten super used to "discard changes" as a means of signalling "on second thought, don't do anything".

[–] ulterno@programming.dev 1 points 1 hour ago

That's definitely how it is seen.
If I were to see "Discard Changes" anywhere in a dialogue, I would assume it will discard whatever changes I made in that dialogue. In this case, probably some source control related changes. If it were to say "Warning: This will Discard ALL changes!!!", I might do a double take, but had I never used git CLI before, I would still assume that at most it would discard "ALL" changes made in the current session.

For me personally, I would consider it more useful for it to say:

This action will delete the following files:
- followed
- by
- a
- list
- of
- files
- that
- would
- be
- deleted
Continue?

Which neither has to look like a warning, acting like you might be doing something you don't want to and also is much more useful for someone like me who wants to double check what exactly I am deleting.


Also, I have used git CLI before and apart from being able to see blame in the editor itself and maybe a better representation of tree, I don't feel the need to use any git GUI tool. Even when I tried, I realised it was slower and more finicky to use. So, it would stand to reason that it should be targetted towards people who don't use CLI (and might have never used git CLI).

[–] mvirts@lemmy.world 36 points 7 hours ago

Obligatory mention of file recovery as an option if you get in this situation.I recommend testdisk but there are other more gui friendly options.

NTFS takes a relatively long time to destroy the data so chances of recovery are good on Windows.

[–] _____@lemm.ee 105 points 9 hours ago (17 children)

let's turn this into a constructive angle for future devs and current juniors: just learn git cli, I promise you it is much simpler than it seems.

all those memes about git having like a thousand commands are true, but you really will only use like 7 at most per month.

learn push, pull, merge, squash, stash, reset, im probably missing like one or two

I promise you again: it is much simpler than it seems. and you won't have to use these stupid git GUI things, and it will save you a hassle because you will know what commands you are running and what they do

short disclaimer: using git GUI is totally fine but low-key you are missing out on so much

[–] lurklurk@lemmy.world 12 points 3 hours ago

You get pretty far with just clone, pull, add, commit, push

[–] Piatro@programming.dev 6 points 4 hours ago

The main draw to the CLI for me is portability. I've been a dev for ten years now and used tons of different editors on different platforms and while each one had a different way to describe the changes, how to commit, or how to "sync" (shudder), the CLI hasn't changed. I didn't have to relearn a vital part of my workflow just because I wanted to try a different editor.

[–] apostrofail@lemmy.world 4 points 4 hours ago

How about Git’s CLI stop being so shit? All of the options are obtuse & usually 3 ways to do the same thing.

Developers should normalize non-Git DVCSs.

[–] Atlas_@lemmy.world 5 points 4 hours ago

For a first step you can get away with just add, commit, push, and pull. Maybe reset, but tbh using git like svn at first is fine.

Next branch, checkout and merge. At this point show, log, bisect and blame also start to be useful.

I'm not a fan of stash, and would instead recommend reflog and cherry-pick as the first two advanced commands to learn. Then rebase and squash.

[–] sour@feddit.org 60 points 8 hours ago (1 children)

im probably missing like one or two

commit. Lol

load more comments (1 replies)
load more comments (12 replies)
[–] JackbyDev@programming.dev 46 points 8 hours ago

I fucking HATE when abstractions over git use cutesy names that git doesn't use.

load more comments
view more: next ›