
@sameenkarimi
iAccount based inUnited States
About this account
- Account based in
- United States
- Connected via
- United States App Store
Account-level information from X, not a live location or the device used for a specific post.
Product @github leading Stacked PRs 🥞 Previously @rockerbox, @eventable Proud @UCBerkeley dropout
New York, NY
Joined February 2012
- Tweets596
- Following544
- Followers1.3K
- Likes630
Agents don’t just help build features. They can help try to break them, too.
In our latest GitHub Podcast episode, Sameen Karim takes us behind the scenes on building stacked PRs. Listen to it wherever you get your podcasts or at youtu.be/sbHoDdAalMI?si=purN…
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: youtu.be/sbHoDdAalMI
Sameen Karim retweeted
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: youtu.be/sbHoDdAalMI
Note: we will still dismiss approvals for conflicts or mid-stack changes, because that would result in changes that are no longer tree-same
More on the latest set of updates to stacks here 👇
github.blog/changelog/2026-1…
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
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

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.
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
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
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 ⚡️
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…
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…
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
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…







