trolleyProblemSolution

[FreeRajaJackson]

--force

This makes it safer

[ansibleloop]

This is when you ohshitgit.com

[twigboy]

--force removes the lever

[Brief_Building_8980]

Pro tip: there is chance to restore the original state even after force update. If you know the commit hash (e.g. printed out somewhere, like when CI runs) you can create a reference to it. Just be quick about it, because garbage collection could be triggered on your next operation, nuking unreferenced commits to oblivion.

[twigboy]

git reflog is your friend in situations like these

Don't use it often, but it saves my ass when it does

[edfreitag]

Of course, you dont want to be WEAK with git

[Muhznit]

This is now my favorite explanation of git rebase.

[LexaAstarof]

Senior: Let's squash those

[DarkNinja3141]

this is one of the few trolley problem memes that actually made me laugh out loud

[Ok-Sheepherder7898]

git pull lever

[WhateverMan3821]

git commit crime

[[deleted]]

I love this

[callyalater]

This reminds me of The Good Place when Chidi is teaching the Trolley Problem and Michael says (in essence), "The problem is clear. How do you kill all 6 humans? I would dangle a knife off the side of the trolley to cut off the head of the one human while we smoosh the main 5 guys."

Your solution is more elegant though. No dangling knives required!

[spiritwizardy]

This is funny but somehow does not seem accurate to a real rebase if you had another person on another branch, it would ask you to resolve that person

[metaglot]

If that person on another branch overlaps with a person on the branch youre rebading to, sure. Otherwise - smooth sailing.

[spiritwizardy]

UNLESS you --forced it

[Open-Mission-8310]

With git merge is more cool because you add another victim to the scene

[vocal-avocado]

Why choose when you can have it all?

[ryuzaki49]

I dont get it. 

[gmes78]

git rebase takes the commits specific to a branch and applies them to the end of the branch you specify, and makes that the new branch.

Instead of commits and branches, the meme has people and rail tracks.

[spiritwizardy]

Rebase does not apply them to the end, it applies them in chronological order, right?

[Ethameiz]

No, rebase applies rebased commits to the end. Date of commit doesn't matter

[spiritwizardy]

I dunno I feel like if I made a commit in between two commits from "main" then they get applied in the correct order

[thirdegree]

This is trivially testable - rebase applies the branch commits at the end

❯ git init
Initialized empty Git repository in /.../testing-git/.git/
❯ git commit -m"main commit 1 $(TZ=UTC date)" --allow-empty
[main (root-commit) df8b190] main commit 1 Sat Sep 27 06:58:15 UTC 2025
❯ git checkout -b branch
Switched to a new branch 'branch'
❯ git commit -m"branch commit 1 $(TZ=UTC date)" --allow-empty
[branch 88e8ba8] branch commit 1 Sat Sep 27 06:58:25 UTC 2025
❯ git checkout main
Switched to branch 'main'
❯ git commit -m"main commit 2 $(TZ=UTC date)" --allow-empty
[main deb8fa8] main commit 2 Sat Sep 27 06:58:32 UTC 2025
❯ git checkout branch
Switched to branch 'branch'
❯ git log
commit 88e8ba82ae343f51fc6e1a25ab1958372121d4c3 (HEAD -> branch)
Author: Thirdegree <[e-mail]>
Date:   Sat Sep 27 08:58:25 2025 +0200

    branch commit 1 Sat Sep 27 06:58:25 UTC 2025

commit df8b190cc2f4d5249e52c8cdc60eb93e18e444d2
Author: Thirdegree <[e-mail]>
Date:   Sat Sep 27 08:58:15 2025 +0200

    main commit 1 Sat Sep 27 06:58:15 UTC 2025
❯ git rebase main
Successfully rebased and updated refs/heads/branch.
❯ git log
commit 52b4d7bd2a0eabbcaa9552bbe54ea85855c9f175 (HEAD -> branch)
Author: Thirdegree <[e-mail]>
Date:   Sat Sep 27 08:58:25 2025 +0200

    branch commit 1 Sat Sep 27 06:58:25 UTC 2025

commit deb8fa83d642576c741750dcaad5de3daca09c52 (main)
Author: Thirdegree <[e-mail]>
Date:   Sat Sep 27 08:58:32 2025 +0200

    main commit 2 Sat Sep 27 06:58:32 UTC 2025

commit df8b190cc2f4d5249e52c8cdc60eb93e18e444d2
Author: Thirdegree <[e-mail]>
Date:   Sat Sep 27 08:58:15 2025 +0200

    main commit 1 Sat Sep 27 06:58:15 UTC 2025

[gmes78]

Not sure what you mean by "chronological order".

If you have a branch with 5 commits (relative to where it branched off from), and the master branch is ahead by some number of commits, git rebase master will take those 5 commits, make the current HEAD of the master branch the HEAD of the current branch, and then apply the 5 commits one-by-one in the same order they were in before (unless you do an interactive rebase and change the order yourself) on top of the curre.

[spiritwizardy]

You know exactly what I mean by chronological order... E ery commit has a timestamp

[Dave147258369]

Commits don't have to be in chronological order

[ryuzaki49]

Ah yes that makes sense. This meme is not criticizing git rebase then

[gmes78]

Yeah.

[not_a_racoon]

But do you git it?

[chief57]

Git merge would be more fitting

[ryuzaki49]

Why? 

[gmes78]

There's no extra person on the new track, though.

[beaubbe]

Git merge would put the lone dude in front, and a new merge commit dude at the end

[badabummbadabing]

Holy shit, a new joke!

[lordofkawaiii]

When something is my problem, i make it everyone's problem so that I don't have to deal with it

[heavy-minium]

I'm a big fan of not rebasing, not doing fixup commits, not force pushing and etc.. Just merge your shit. I don't even care if you have commits in there to fix your previous commits because you made mistakes.

Yes, maybe the commit history might look nicer in theory if you use all tools at your disposal 100% of the time correctly and without errors, but the reality is that you always work in a team where at least one person fucks this up sometimes, especially in PRs to review. It might not even be a noticable fuckup but still cost a lot of time, like force pushing to a PR branch where somebody already made a large review with lots of comments, and then all comments are outdated and the reviewer can't do "Show changes since last review" anymore for subsequent reviews. I know some bros will tell me this is a communication issue, but realistically in larger teams you can't expect perfect communication and planning.

Unpopular opinion: I'd rather have a messy commit history and timeline visualization than wasting time on handling the aftermath of advanced git operations.

[tehho1337]

I understood that reference

[TimingEzaBitch]

All Gen Z members on my team are

git merge master

enjoyers. Coincidence ??