December 5, 2025
Rebasegate: code Jenga edition
Stacked Diffs with git rebase —onto
Dev world splits: lifesaver trick or house-of-cards headache
TLDR: A guide touts git’s rebase --onto to move only your intended changes and keep stacked, bite-sized pull requests neat. Commenters clash: skeptics fear a fragile setup, pragmatists prefer interactive rebases, and tool fans push git-spice or Jujutsu—proof small reviews can spark big feelings.
Git’s latest debate: a guide says the magic spell “rebase --onto” keeps a stack of small pull requests tidy—like moving only your LEGO piece without dragging the whole tower. The pitch: smaller reviews, faster approvals, fewer messes. But the crowd? Oh, they’re split. One self-described “shmedium” dev calls the whole thing a “house of cards,” worrying one forgotten command will blow up history. The cautious camp nods along: better to do an interactive rebase (a step-by-step edit) so you can see exactly what gets dropped. Meanwhile, the tool fans roll in like a street team. A power user gushes they “can’t go back” after git-spice, while nostalgically name-dropping Facebook’s Phabricator. Another voice says the real hero is “update-refs,” and a third says skip the drama and try Jujutsu instead. The drama peaks over complexity: is “--onto” a clean trick or a footgun with an IKEA manual? The article’s insistence on carefully updating “markers” becomes the plot twist—lifesaver to some, booby trap to others. Still, everyone agrees on one thing: giant, single mega-changes are misery. The real fight is over how to keep those bite-sized changes stacked without turning your repo into a Jenga tower.
Key Points
- •The article promotes stacked diffs (dependent PRs) to improve review quality but notes the complexity of keeping branches in sync.
- •Regular git rebase can cause problems in stacked branches because upstream rebases change commit hashes, leading to duplicated or conflicting commits downstream.
- •git rebase --onto (<new-base> <old-base> <branch>) moves only commits after the old base onto a new base, preventing unrelated commits from being included.
- •A practical workflow includes creating a marker branch when forming a dependent branch and updating that marker during each sync to enable repeatable rebases.
- •After an upstream branch merges into main, use interactive rebase to drop those upstream commits from the dependent branch and replay only its own commits onto main.