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
Filter
Exclude
Time range
-
Minimum likes
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
315
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,456
Replying to @stratocastee
💯 as someone who personally is allergic to merge commits and always uses rebase, this has been one of my biggest gripes. It’s been my personal mission since I joined gh to make rebasing a better experience. More to come here!
1
3
111
Replying to @japborst @github
We’re working on it! Will be rolling out soon 🫡
8
273
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
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
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
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
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,119
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,825
Replying to @flybayer @BrettDavies
You can customize your CI to run only for the top of the stack (e.g. while in draft) docs.github.com/en/pull-requ…

Optimizing CI for stacked pull requests - GitHub Docs

Understand how GitHub Actions workflows run for a stack, access stack metadata in your workflows, and reduce redundant CI usage.

docs.github.com
2
2
94
Replying to @flybayer @jacobmparis
If you hit merge on the nth PR, it will generate all n merge commits, make one push to main, and mark all the PRs as merged. It doesn't happen one at a time
1
60
Replying to @sameenkarim @flybayer
We recently updated how stacks work in merge queue to ensure PRs always land in the same merge group. We're working on another update so CI only runs for the head PR in merge queue instead of each individual PR
3
137
Replying to @flybayer
Stack merges are atomic. When you merge multiple PRs in a stack, it creates all the merge commits and makes one push to main. Your CI should then run off the head commit
2
6
746
Replying to @erkamyaman_ng @github
1
3
67
Sameen Karim retweeted
erKam 🅰️
@erkamyaman_ng
Oct 7
stacked PRs be like
1
2
123
Replying to @smanojshere @github
If you have a rule that allows bypass, you can use it to skip approvals. Doesn’t matter how many approvals are are needed The limitation is you must bypass on one PR at a time (can’t bypass and merge multiple PRs in one click)
1
33
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. nitter.siddz.com/i/article/210757850709…

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
Replying to @johnbarker @github
We discussed this and it would violate too many of our internal models unfortunately. Merging multiple PRs into one commit would cause issues with reverting PRs and associating approvals/rule evals to merge commits
1
251
Load more