If you've ever royally fucked something up in git, that hotline is necessary
this post was submitted on 07 Feb 2025
733 points (99.1% liked)
Programmer Humor
33315 readers
880 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
How dare you! First of all, it's a beautiful distributed graph theory tree model...
I have been that friend from the alt text at every place I have worked. I shudder to think how they're going about their projects without me, now.
I'm kinda planning on teaching my team how to use interactive rebases to clean the history before a merge request.
The first thing they'll learn is to make a temporary second branch so they can just toss their borked one if they screw up. I'm not going to deal with their git issues for them.
I'm kinda planning on teaching my team
I'm not going to deal with their git issues for them.
These two statements contradict each other.
I disagree. I don't wanna deal with my coworkers work, so I'm teaching them to deal with it themselves. Not necessarily in the best way for them to do it, but in an easy way to teach and an easy way to get right
That's why I'll make damn sure they'll make that second branch first.
Mind you, the most likely result is that I'll still see branches with 50+ commits with meaningless names because nobody ever rebases anything.
Never understood why this is such a trope. There's very little you can't recover in git (basically, only changes you never committed in the first place).
Have you ever tried a rebase?
Not sure if serious or not, but yeah I use interactive rebases every day, many times a day (it's nice for keeping a clean, logical history of atomic changes).
It's very simple to recover if you accidentally do something you don't intend (git rebase --abort if the rebase is still active, git reflog to find the commit before the rebase if it's finished).
IN CASE OF FIRE:
1. git commit
2. git push
3. exit buildingTHE CAUSE OF FIRE:
1. git pull
2. merge conflict
3. starting fire
No AI summary 😍
You can prevent suicide by eating a pizza made with glue ✨✨
Prevent or commit?
Probably because of the word conflict being a trigger word.
It's cropped out u_u
git gudgit push --force
"Fuck the code review!"
It moves the suicide to the other end of the repository.
sounds about right
I actually feel disgusted when I see Google search now. It’s just so bad that even the logo does it.
Aww hang in there little fella
I will say. if you have no idea at least clone your branch so you can experiment on it.
Experiment on the suicide hotline? I'm sure they won't appreciate that!
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.
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.
Magit for Emacs is an excellent tool for resolving conflicts.
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.
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.
Praise be Magit, which actually allows me to handle stuff like that moderately confidently.
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"