maiao: Gerrit-style stacked diffs for GitHub, Cursor Origin, GitLab, Codeberg and more
2 points by joaoqalves
2 points by joaoqalves
There are dozens of these types of projects. Graphite was one (but I think they might have pivoted, I'm not sure), jj is trying to fill this space, now there's maiao, and there's a bunch of others.
They all fundamentally work the same way: a stack of commits turns into a github set of PRs, each with a different branch, and they play magic games behind the hood to keep the branches in order.
The fact that none of these tools has taken off and become mainstream I think indicates that a stacked commit workflow is fundamentally at odds with github's design. I'm kindof coming to the conclusion that stacked commits will never work well with the "pull request" model, and we need some other type of "forge" (ugh I hate that term) to take over if we want to use stacked commits as a workflow.
(NB I haven't tried the new github stacked commit feature yet, but everything I've read about it makes it seem pretty lackluster)
Hi! Maintainer and OP here.
There are dozens of these types of projects. Graphite was one (but I think they might have pivoted, I'm not sure), jj is trying to fill this space, now there's maiao, and there's a bunch of others.
Jujutsu is a different project with similar purposes. The point of maiao is to enhance GitHub — and now, other forges — experience without a change on the underlying model. Everything is still a git commit. There's no "new API" or commands to learn, besides git review. It's a simple automation that creates/updates chained PRs, using GitHub's API. To work seamlessly, it relies on Gerrit's Change-Id concept and hook.
Note that Graphite and other projects introduce the concept of stack as a central piece. That creates a new API/UI to learn, atop git. It may give a better experience, at the expense of diverging from the "it's just git" concept. Also, Graphite was bought by Cursor — now, both are part of SpaceX — and I think they monetized it. Maiao has none of these goals in mind.
They all fundamentally work the same way: a stack of commits turns into a github set of PRs, each with a different branch, and they play magic games behind the hood to keep the branches in order.
Based on the above, I'd say the magic is rather transparent.
The fact that none of these tools has taken off and become mainstream I think indicates that a stacked commit workflow is fundamentally at odds with github's design. I'm kindof coming to the conclusion that stacked commits will never work well with the "pull request" model, and we need some other type of "forge" (ugh I hate that term) to take over if we want to use stacked commits as a workflow.
I tend to agree. There are two realities, though:
GitHub is the default forge, so it's not practical to ask the critical mass to switch to a better/more-elegant alternative.
In some companies, you also don't get to choose. You get GH, Gitlab, etc. So, providing a progressive enhancement that doesn't break anyone else's flow and allows you/your team to work with granular commits is already a win.
The important part of Gerrit is that you review commits. You can comment on every part of the the commit, including the commit message. Gerrit tracks the history of the commit over time, it doesn't invalidate review comments just because a new version of the commit has been pushed. If one still has to use the GitHub for reviewing changes it is not a meaning improvement.