Stacked Diffs Split the Change, Not the Reviewers

maiao v1.4.0 was published on 25 August 2026, twenty-six days after GitHub put its own stacked pull requests into public preview. Both implement the same idea — stacked diffs, one reviewable commit per pull request, each targeting the one below it — and that gap is why the third-party tool is worth looking at now. Until this summer the argument for maiao was that GitHub could not stack. That argument is gone, and what replaced it is narrow enough to decide whether you install anything at all.

What it does

maiao adds a git review command. It reads the commits on your branch, opens one pull request per commit, and points each at the one below. Commits are tracked across rebases by Change-IDs written by the Gerrit commit-msg hook, so amending a commit updates its existing pull request instead of opening another, and git commit --fixup is the documented way to answer review feedback.

The v1.4.0 release notes list provider detection infrastructure, provider-aware credential resolution, and pull or merge request support for GitLab, Gitea, Forgejo and Bitbucket Cloud, plus beta support for Cursor Origin. The README lays out that the six are not equivalent: draft state is an API field on GitHub and Cursor Origin, a title prefix on GitLab, Gitea and Forgejo, and unsupported on Bitbucket Cloud. Native stack registration exists on three of the six.

Those native stacks are a progressive enhancement rather than a dependency. Once two or more pull requests are pushed, maiao probes the GitHub Stacks API, caches the answer for 24 hours, and registers the stack when the host supports it. git config maiao.useNativeStack accepts auto, true or false.

Where GitHub's own stacked diffs stop

The changelog says stacks were rolling out to all repositories, with merge queue support following over the coming weeks, and names no limits. The documentation names several.

Every branch in a stack must live in the same repository — cross-fork stacks are not supported. That excludes the standard open-source contribution flow, where the contributor pushes to a fork. Stacked pull requests are also unsupported in GitHub Desktop. Merging through the API requires the asynchronous merge endpoint rather than the ordinary synchronous one, which any automation you have written against pull request merges will have to account for. The CLI reference adds that merge requirements cannot be bypassed on a stack, that an enabled merge queue takes the stack rather than merging it directly and ignores merge method flags, and that the extension needs gh 2.0 or later.

So the case for maiao is no longer that GitHub lacks stacked diffs. It is that your engineers do not all push to github.com, and you want one command that behaves the same on GitLab, on a self-hosted Forgejo, and on Bitbucket Cloud.

The repository is its own case study

The commit history here is worth reading, because maiao ships itself using maiao.

The whole multi-provider feature set arrived as one stack. Twelve pull requests, numbered between 12 and 24, were opened on 21 August — ten inside thirteen seconds, which is what one git review looks like from outside. They merged on 25 August between 13:13 and 13:47 UTC, and the release went out at 13:54. Together they added 3,976 lines and removed 284.

Eight of the twelve carry an approving review from a second account. Four do not: the missing-remote-HEAD fix, the error-surfacing fix, the Cursor Origin provider, and — the one worth noticing — the fix for a base branch conflict in GitHub native stack registration.

That is the honest measurement of what stacked diffs buy. A single pull request of that size would have been reviewed by nobody in any useful sense; twelve smaller ones drew eight real reviews. The unit of review changed and the outcome improved. What did not change is the number of people available to review, and the four unreviewed pull requests are where that shows. GitHub's own engineering post offers stacks as the answer to a 1,721-line agent-generated pull request. It is a good answer to the reviewability half of the problem and no answer at all to the capacity half — the same split described in why enterprise AI doesn't ship: the tooling arrives long before the human process it depends on.

Maturity, in numbers

maiao is a community fork. The upstream, adevinta/maiao, was last pushed on 8 July 2026, is not archived, has 156 stars and carries 6 open issues.

The fork was created on 1 April 2026. Since then it has taken 34 commits: 31 from one account, two from a release bot, one from a second person. It has 88 stars, zero forks and zero watchers. Its only two published releases are dated 24 and 25 August, and the release-please automation behind them landed in v1.3.0.

The issue tracker is switched off. There is nowhere to file a bug.

Two smaller frictions. Neither release publishes a binary, so the Homebrew formula in the repository builds from source, needs a Go toolchain, and declares a conflict with the git-review package because it installs a binary of that name. And go.mod still declares the module path under adevinta, not runetes.

Who should not use it

If every repository you care about is on github.com and nobody contributes from a fork, run gh extension install github/gh-stack and stop here. You get stacks your existing reviews, checks and merge requirements already understand, maintained by the company that owns the merge button.

If you are spread across hosts, maiao is worth one team's trial, with eyes open about who maintains it. Before that trial, price the maintenance risk:

gh api repos/OWNER/REPO --jq '{issues:.has_issues, watchers:.subscribers_count, forks:.forks_count, pushed:.pushed_at}'
gh api --paginate 'repos/OWNER/REPO/commits?since=2026-04-01T00:00:00Z&per_page=100' --jq '.[].author.login' | sort | uniq -c | sort -rn

Three thresholds worth writing down. A has_issues of false means no channel to report a defect and no public record of anyone else's. One account above 80% of post-fork commits — here, 31 of 34 — means the project is one person's calendar. And a release pipeline whose first run is under a month old has not been exercised against a bad release, which is the standing-operations line item that getting from PoC to production covers.

What would show this reading is wrong: if GitHub's stacked pull requests leave preview with cross-fork support, the multi-host argument is the only one maiao has left, and for a github.com-only organisation the right number of third-party stacking tools becomes zero. The line to watch is the cross-fork sentence in the documentation, not the next changelog entry.