Stacked Diffs with git rebase —onto

Original Article ↗ Hacker News Discussion ↗

Perception of the article’s rebase --onto workflow

  • Some find the marker-branch + rebase --onto flow clever but fragile and easy to forget, describing it as “house of cards”–like.
  • Others prefer simple, explicit interactive rebases (git rebase -i origin/main) and manually dropping merged commits because they can see every step.
  • Concern that forgetting a step (e.g., marker branch updates) could corrupt or confuse history, especially for infrequent users of stacked workflows.

git rebase --update-refs as a better solution

  • Many commenters point out that --update-refs essentially automates what the article is doing manually and often removes the need for marker branches.
  • Key advice: run git rebase --update-refs <base> <outermost-branch> and Git will update all descendant branch refs that point into the rebased range.
  • It works best when branches are strictly stacked (each branch starts from the tip of the previous); it’s less general for arbitrary branch trees.
  • Limitations noted: can break if you amend the top commit instead of adding a new one; added only in Git 2.38, so it’s relatively recent and poorly discovered.

Alternative tools and workflows

  • Tools mentioned that simplify stacked diffs: git-spice, git-machete, Graphite, GitButler, stacked-git (stg), git-town; some teams rely on these to avoid “git gymnastics.”
  • Several people advocate Jujutsu (jj) and its TUI (jjui) as fundamentally better for stacked changes: automatic rebasing of dependent branches, bookmarks that track “changes,” first-class conflicts, easy undo, anonymous branches.
  • Others are happy with GUI/CLI frontends on top of Git (lazygit, Sublime Merge) or extensions like git machete and don’t want to learn a new VCS.

Debate: stacked diffs vs trunk-based / small-PR workflows

  • One camp sees stacked diffs as a workaround for too much work-in-progress; they recommend trunk-based development, feature flags, and always-mergable small PRs.
  • Another camp argues that dependent features and multi-PR changes are normal, and stacking lets you keep each PR small without waiting for the previous to merge.

Git usability, philosophy, and discoverability

  • Some argue Git is fine if you learn its model; rebase -i, --autosquash, --update-refs, and fixup commits already cover most needs.
  • Others feel Git’s UX is unnecessarily complex, and jj’s model (operation log, automatic descendant updates, deferred conflict resolution) better matches how they think.
  • There’s broad agreement that Git’s discoverability is poor; many only learn about powerful flags like --update-refs from peers, not docs.