this post was submitted on 30 Apr 2026
522 points (99.2% liked)

Programmer Humor

31299 readers
1041 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 2 years ago
MODERATORS
Feyter@programming.dev
anzo@programming.dev
BurningTurtle@programming.dev
pylapp@programming.dev
522
Please let me squash a merge commit (sh.itjust.works)
submitted 1 week ago by jxk@sh.itjust.works to c/programmer_humor@programming.dev
50 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] pupbiru@aussie.zone 1 points 3 days ago* (last edited 3 days ago) (1 children)

Squashed commits are not atomic … overall task requires modifying multiple different systems

that’s why monorepos exist

i’d say squashed commits aren’t always atomic, but this is one of the biggest reasons people add the complexity of a monorepo: if changes cross multiple systems, ideally their merge/revert should be an atomic operation

you either have deployment complexity (ensuring the feature is in all deployed systems before switching over), code complexity (dealing with the feature only maybe exiting in parts of the system), or repo complexity (where tools manage a monorepo and thus commits and PR/MRs are atomic across your system)

[–] expr@piefed.social 1 points 3 days ago (1 children)

Monorepos don't really change anything. Squashed commits are still not atomic, unless the MR is small enough to fit into a single logical commit. Changes made to say, a database query are distinct from changes made to route handling, yet both might be needed for the overall feature. They don't belong in the same commit in history.

[–] pupbiru@aussie.zone 1 points 3 days ago

hard disagree on what belongs in the same commit history… a single merge should be an entire feature, and your commit history should read like a change log