Sameen Karim
@sameenkarim

Product @github leading Stacked PRs 🥞 Previously @rockerbox, @eventable Proud @UCBerkeley dropout

 New York, NY
sameenkarim.com
Joined February 2012
96 Photos and videos
One of the key design decisions we made with stacked PRs was reusing the existing PR model. It definitely came with some drawbacks, but it’s what made it possible to ship the feature without needing to rewrite all of the core plumbing (and we still had to update a lot!) More on how we built stacks on the latest episode of the @github podcast: piped.video/sbHoDdAalMI

How stacked PRs work behind the scenes at GitHub | S02E05 | The GitHub Podcast

In episode 5 of season 2 of The GitHub Podcast, Cassidy and Andrea ...

youtube.com
1
1
314
Sameen Karim retweeted
Andrea
@acolombiadev
Oct 16
stacked prs @github behind the scenes. the merge box is way more complex than you think, we touched code that hadn't been updated in a decade, and we set a swarm of agents loose trying to break it 🤯 full episode: piped.video/sbHoDdAalMI
1
6
17
2,453
Note: we will still dismiss approvals for conflicts or mid-stack changes, because that would result in changes that are no longer tree-same
1
2
549
More on the latest set of updates to stacks here 👇 github.blog/changelog/2026-1…

Stacked pull requests generally available - GitHub Changelog

GitHub stacked pull requests are now generally available. Break large changes into smaller, focused pull requests that you can review independently and merge together. Since the feature went into...

github.blog
1
4
1,015
To solve this, we now record the merge-base SHA of the entire stack alongside each review. This is the common ancestor of the reviewed head and the stack's base branch, giving us a reference point for checking the whole stack up to that PR
Record stack merge-base as part of approval. Main runs from A to B. The blue stack branches from A to X, the head of PR 1, then Y, the head of PR 2. The approval on PR 2 saves reviewed head Y, its PR merge-base X, and stack merge-base A. A is the common ancestor of main and Y.

ALT Record stack merge-base as part of approval. Main runs from A to B. The blue stack branches from A to X, the head of PR 1, then Y, the head of PR 2. The approval on PR 2 saves reviewed head Y, its PR merge-base X, and stack merge-base A. A is the common ancestor of main and Y.

1
6
626
We simulate merging the previously approved head with the new stack merge-base, then compare that result's git tree with the rebased head's tree. If they match and the review's recorded merge-base is still valid, we promote the approval to new head commit
Main runs from A to B. The blue branch contains X (from previously approved PR 1) and Y (from previously approved PR 2), branched off A from main. The green branch contains the rebased stack of branches, off B in main, with X prime (PR 1) and Y prime (PR 2). The dashed orange line simulates merging Y with B, yielding M (simulated merge result). Then Y prime and M are compared, confirming that both are tree-same, so the approval is retained.

ALT Main runs from A to B. The blue branch contains X (from previously approved PR 1) and Y (from previously approved PR 2), branched off A from main. The green branch contains the rebased stack of branches, off B in main, with X prime (PR 1) and Y prime (PR 2). The dashed orange line simulates merging Y with B, yielding M (simulated merge result). Then Y prime and M are compared, confirming that both are tree-same, so the approval is retained.

1
4
524
Approvals are now retained for Stacked PRs after stack rebases ✅ Whether you use the "Rebase stack" button or partially merge a stack, as long as the diff doesn't change, PR approvals will be kept even if you have "dismiss stale approvals" turned on
16
31
411
43,819
more replies
The challenge was telling the difference between replaying the same reviewed changes on a new base vs. actual changes that have been introduced that need another review. In a stack, that means accounting for the PRs below, too
Before and after an unchanged stack rebase. Main advances from A to B. The original blue stack branches from A through X and Y, the heads of PR 1 and PR 2. Replaying them on B produces green X prime and Y prime on a branch below main: new commit IDs representing the same reviewed changes.

ALT Before and after an unchanged stack rebase. Main advances from A to B. The original blue stack branches from A through X and Y, the heads of PR 1 and PR 2. Replaying them on B produces green X prime and Y prime on a branch below main: new commit IDs representing the same reviewed changes.

1
4
818
PR approvals are tied to commit IDs and since a rebase/force-push rewrites those, it would previously always result in reviews being dismissed. We do have a system for "promoting" approvals but historically it only worked with merge commits
1
4
1,118
Sameen Karim retweeted
erKam 🅰️
@erkamyaman_ng
Oct 7
stacked PRs be like
1
2
123
So much exciting work happening in git systems right now! Moving to blob-storage and decoupling compute while simultaneously unwinding mountains of tech debt and unnecessary dependencies. 35x higher write throughput ⚡️
GitHub
@github
Oct 6
Git activity more than doubled between September 2025 and August 2026, reaching 473.3B events per month. We’re rebuilding our Git infrastructure while GitHub keeps running, creating a foundation for agent-scale software development.
Article

Building Git infrastructure for agent-scale development

By Brian Celenza Every day on GitHub, millions of developers build the products their customers rely on, contribute to open source, and pursue personal projects. GitHub’s architecture has changed

1
9
569
gh stack CLI now supports git worktrees 🥞 You can manage stacks where each branch is in a separate worktree, while still taking advantages of things like cascading stack rebases github.com/github/gh-stack/r…
24
44
332
40,506
Excited to release the @github async merge API today! If you (or your agents) are merging PRs programmatically, this is for you 🧵 github.blog/changelog/2026-1…

GitHub async merge API generally available - GitHub Changelog

You can now use the generally available GitHub async merge API to merge individual or stacked pull requests, add pull requests to a merge queue, or merge pull requests directly.…

github.blog
17
25
509
73,280
more replies
Some of the largest monorepos are now using this API for their agent-scale workloads - it's already accounting for ~1% of programmatic merges with a 34% lower error rate Platforms like @cognition and @trunkio have also updated their integrations to leverage the async merge API
1
12
2,034
Check out the docs to get started 👇 And let us know what you think! What other APIs should we build? docs.github.com/en/rest/pull…

REST API endpoints for pull requests - GitHub Docs

Use the REST API to interact with pull requests.

docs.github.com
6
1,772
Should we add keyboard shortcuts for navigating stacked PRs?
3
1
9
531
Load more