Hacker News Reader

Can you make sure there is good API support for stacks?

We use a custom merge queue and we want it to be able to land multiple PRs from a stack at once as separate PRs. Last I checked you had to land a single PR, rebase the stack, land the next and so on. This is very expensive in CI time (and wall clock time), vs simply testing part or all of a stack in parallel then declaring those merged. In essence a robot needs the ability to say “squash merge these 3 stacked PRs”, after the queue does its thing.

Yes that was one of our top priorities. For one, there's a fully public API for all stack operations. So if you don't want to use the `gh stack` CLI, you can build your own: https://docs.github.com/en/rest/pulls/stacks

For merging, we have an API but had to move it to a new async method: https://github.github.io/gh-stack/reference/merge-api/

The legacy API was fully synchronous, and since stacks of multiple PRs can often take more than 10s (our global timeout), we had to move to async.

We've had some folks already use this to integrate stacks into their merge queues. The great part is you can land multiple PRs in one atomic operation, and then there's one push to main with all your commits from multiple PRs. So instead of having to rerun the build/deploy for each, it can trigger for the last commit that contains all of the changes.

Is there also a webhook? I don’t fancy busy-looping on dozens or hundreds of PRs for tools with large scopes of overview.

Also what about external merges? Is there a way to sanely interact with stacks when merging locally or via external tooling?

Hey there - we worked with Sameen and the team at GitHub over the past month to get support for stacks in our Mergequeue: https://trunk.io/blog/trunk-merge-queue-now-supports-github-...

They do indeed have APIs you can use in your mergequeue, I'm happy to share notes on how we built it so you can add it to your mergequeue.

Does trunk use GitHub’s api to merge stacks, or does it do the integration internally / on its own?

We use GitHub's APIs. We did build a version before GitHub supported it, but it required using our credentials to push directly to the main branch. That wasn't acceptable to most of our customers, so we ended up not shipping it and waiting for GitHub support.

Using the GitHub APIs means you still preserve history and commit messages they way people expect (merges through the queue and direct merges behave the same), and it lets users guarantee that the only code our mergequeue merges is the code that was in the PR.

lovely website animation :D

Thanks! :)

> There's an internal system we have called CPRMC (Create Pull Request Merge Commit) that is used to evaluate whether a PR is "ready" to merge. This covers everything from mergeability (checking for merge conflicts) to rule evaluations (ensuring that approvals match the potential commit that will be created by merge) and more.

By the way could there be a way to disable that when doing integrations externally? It seems to be quite costly (which makes sense), and the pull/ refs kinda bloat the reflist.

I’m sure that external integration is not exactly beloved internally but there’s really just a small handful of big annoyances which would make it so much nicer and more comfortable.

The feature is half baked. Just today I had to spend ~1hr untangling a mess it created. And there was no way to reorder the Stack without discarding PRs that already had many comments. I'm not an intentional an early adopter, someone on the team clicked the tooltip.

> This becomes particularly difficult when squash merging a stack of multiple PRs

I acknowledge that it is not trivial.

But this is 2026. Many people have solved this in in-house solutions. Every place I have worked at in the last 10 years had solutions in place. Some had wrinkles but it all worked in the end. Github sees itself as the leading provider of solutions in that space and has MSFT backing. Just saying that it's difficult is not good enough, quite frankly. People have been complaining about GH support for this for a long time.

> But this is 2026. Many people have solved this in in-house solutions. Every place I have worked at in the last 10 years had solutions in place. Some had wrinkles but it all worked in the end. Github sees itself as the leading provider of solutions in that space and has MSFT backing. Just saying that it's difficult is not good enough, quite frankly. People have been complaining about GH support for this for a long time.

But most of those solutions don't have the number of integrations and rules executions that GH has and that's where the challenge lies.

Again, it's by no means trivial. But in the last years we as an industry made private space travel viable, created self driving cars and made chatbots that can explain humor. Not being able to do stacked PRs in this day and age by the prime company in this area is just .. well you got the point.