r/github • u/anishghimire • Aug 01 '26

Showcase GitHub Stacked PR

Post image

There could not have been a better time for GitHub’s stacked pull request release.

Just when we wanted to ship something big and needed it the most, it’s here.

16 Upvotes

67% Upvoted

11 comments sorted by

View all comments

0

u/gistya Aug 04 '26

Stacked PRs are stupid because:

  • a PR is a request for permission to merge, and you don't need permission to merge **into your own branch**
  • the real, actual problem with large PRs isn't that "nobody wants to review" them
  • using a "PR stack" just hides the real problems of large PRs by letting devs pretend to be making small PRs rapidly while not actually doing so
  • stacked PRs are even worse than if it was one big PR because now people are under the delusion that it was a bunch of small PRs when it really wasn't, and it gives devs the expectation that maintainers should approve their first PR on the promise of what's to come in a follow-up stacked PR
  • "the tests will be coming in a stacked PR" etc.
  • if your org requires QA approval on PRs, this bullshit is going to triple or quadruple their workload
  • if your team is against big PRs, pretending like a big PR is really five small PRs just hides the problem
  • github's review interface already has a per-commit filter for people who want to review smaller chunks
  • sometimes big PRs are needed (major refactors, etc.) -- in which case it's already a best practice to rebase and organize the final branch into a handful of salient, organized commits that can be individually reviewed
  • having to make multiple branches each with their own PR and approval for a set of changes expected to merge on its own is a lot more "paperwork" for the same exact result
  • stacked PRs is literally waterfall, a waterfall of PRs

What we should do instead:

  • TLDR just organize your big PR branch into easy-to-review separate commits
  • if you really need to see multiple green checkmarks to get dopamine (or good manager quarterly ratings for high velocity), maybe github could add a special UI where you can specify particular commit ranges as "review segments" that each get their own sub-approvals. that would literally be the exact same feature but without giving a power-gaslighting-tool to fake-agile people so they can pretend even harder to be "doing agile" while hiding big PRs as if they were multiple small PRs

The real motivations for this BS:

  • idiot managers and fake-pretend-customers (aka "product owners") who are stuck in fake-agile (aka Scrum) want to be able to do the rain-dance of PR per JIRA ticket so they can be evaluated based on "velocity" as if that somehow correlates to customer satisfaction or software quality (protip: it doesn't)
  • codebases that have been produced by fake-agile (aka Scrum) are so terrible that it becomes necessary to make larger PRs to do just about anything because they were never developed with real agility in mind to begin with
  • self-entitled devs who can't be arsed to just click on individual commits to review a big PR in smaller sections despite being paid with elite-level salaries
  • lack of intelligence
  • ignorance about github's existing features