this post was submitted on 07 Feb 2025
759 points (99.1% liked)

Programmer Humor

35551 readers
29 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
all 35 comments
sorted by: hot top controversial new old
[–] braindamagebuddy@lemmy.world 48 points 3 months ago (3 children)
[–] xavier666@lemm.ee 16 points 3 months ago (1 children)

You can prevent suicide by eating a pizza made with glue ✨✨

[–] Kusimulkku@lemm.ee 2 points 3 months ago

Prevent or commit?

[–] A_Very_Big_Fan@lemmy.world 3 points 3 months ago

It's cropped out u_u

[–] fmstrat@lemmy.nowsci.com 3 points 3 months ago

Probably because of the word conflict being a trigger word.

[–] LovableSidekick@lemmy.world 44 points 3 months ago (1 children)
IN CASE OF FIRE:

1. git commit
2. git push
3. exit building
[–] hakunawazo@lemmy.world 30 points 3 months ago* (last edited 3 months ago)
THE CAUSE OF FIRE:  

1. git pull
2. merge conflict
3. starting fire
[–] pfoxx0@lemmy.blahaj.zone 34 points 3 months ago* (last edited 3 months ago) (2 children)
[–] Gork@lemm.ee 22 points 3 months ago

"Fuck the code review!"

[–] hakunawazo@lemmy.world 13 points 3 months ago

It moves the suicide to the other end of the repository.

[–] alphapuggle@programming.dev 32 points 3 months ago
[–] tyler@programming.dev 22 points 3 months ago (1 children)

I actually feel disgusted when I see Google search now. It’s just so bad that even the logo does it.

[–] Reddfugee42@lemmy.world 3 points 3 months ago

Aww hang in there little fella

[–] Hupf@feddit.org 16 points 3 months ago
[–] _____@lemm.ee 8 points 3 months ago (1 children)

I will say. if you have no idea at least clone your branch so you can experiment on it.

[–] pastermil@sh.itjust.works 11 points 3 months ago

Experiment on the suicide hotline? I'm sure they won't appreciate that!

[–] LemoineFairclough@sh.itjust.works 7 points 3 months ago (1 children)

Doesn't git status tell you what to do?

use "git add ..." to mark resolution

use "git commit" to conclude merge

I always use git status to check what is appropriate before doing anything else, since the right thing to do can sometimes be different, like after using git rebase when a break command was used vs when a squash command resulted in a conflict.

[–] Oinks@lemmy.blahaj.zone 3 points 3 months ago (1 children)

To be fair that's not the entire story, since you need to actually resolve the conflicts first, which is slightly scary since your worktree will be broken while you do it and your Linter will be shouting at you.

You may also want a dedicated merge tool that warns you before accidentally commiting a conflict and creating a broken commit.

Oh and non trivial resolutions may or may not create an evil merge which may or may not be desirable depending on which subset of git automation features you use.

Using git status often is definitely good advice though.

[–] goodthanks@lemmy.world 2 points 3 months ago

Magit for Emacs is an excellent tool for resolving conflicts.

[–] umbrella@lemmy.ml 6 points 3 months ago

sounds about right

[–] NigelFrobisher@aussie.zone 3 points 3 months ago

Branching version control was definitely a “they have played us for absolute fools” moment. Especially after all our projects ended up as isolated branches on isolated microservice repositories so basically none of our code was being integrated, let alone continuously. Good for full-remote open source projects where a central admin team has to police submissions though.

[–] PowerCrazy@lemmy.ml 1 points 3 months ago

Git is great. Git is Complicated. But assuming you have a protected master branch that requires PRs and will detect merge conflicts before attempting to merge, it's not really dangerous. It is however frustrating.

[–] exu@feditown.com 1 points 3 months ago

Praise be Magit, which actually allows me to handle stuff like that moderately confidently.

[–] Lightfire228@pawb.social 0 points 3 months ago

I mean, you just need to look at the conflicting files, fix up the code, then stage those changes and pop a new commit

There's no "special" merge conflict resolution commit "type"


As for fixing the code itself, I usually look at what changed between both versions, and then re-author the code such that both changes make "sense"