7 ms·

Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others

114 points by zdw 2mo ago

esafak 2mo ago
Does it use Github's new stacked PR feature? Edit: apparently stacked PRs on GH are older than I thought; the readme references a 2024 blog post about it.
- dietr1ch 2mo ago
  It seems so, https://github.com/runetes/maiao#quick-example https://github.com/runetes/maiao#quick-example As they say in mtg, reading the card explains the card
- joaoqalves 2mo ago
  Hi! Maintainer here. In short: maiao supported stacked PRs on GH, before it existed as a feature :) Now that it's exists (beta), it simply does "progressive enhancement" and adds the PRs to the native stack. But you could still perfectly function without it. That's how maiao works on Codeberg, and Bitbucket, for instance. GiLab has an interesting approach where they auto-stack up until 20 Merge Requests, if they're chained.
martythemaniak 2mo ago
Gerrit. Now that's a name I've not heard in a long time. A long time
jasonlotito 2mo ago
As someone who much prefers Gerrit's UI/UX over GitHub's UI, I was disappointed that this wasn't replicating the UI for GH reviews. Edit: Just to be clear, this is not a blemish on this project. More a lament and a wish someone would create such a thing for those of us forced to leave Gerrit behind for... GitHub. =/
- joaoqalves 2mo ago
  Hi! Maintainer here :) I think some projects already try that. The main goal of maiao is to progressively enhance GitHub with stacked PRs (1 commit = 1 PR) and create as little new API/UI surface as possible. That's why we don't have a `maiao new stack` command. Everything just runs atop normal git with a bit of `git rebase` and automation around GitHub's API. I hope it clarifies the intent.
NamlchakKhandro 2mo ago
Who is creating a separate PR for each commit on their feature/fix branch? sounds like crazy town. I just dont understand why someone would operate like this. Lets assume you're squash merging your feature branchs to your local main, then you're raising the them as prs. why would you do this?
- steveklabnik 2mo ago
  This is standard practice in the "stacked diffs" world: one review, one commit.
- jsphweid 2mo ago
  1 commit == 1 reviewable unit == 1 PR == 1 CL == 1 feature == 1 fix is a perfectly reasonable way of working. I used to work at companies where no one squashed their commits and the entire git logs were filled with 80% non-sense like "temp" or "bad" or "working" with the other 20% being coherent changes. What's the point of doing this I ask?
  - cobalt 2mo ago
    it lets you maintain version history when working, then most workflows auto squash on merge
  - datsci_est_2015 2mo ago
    Well are we talking about commits pre- or post-merge? I don’t care how many commits you put into the PR / MR as long as they squash down to a single commit upon merge.
    - steveklabnik 2mo ago
      When you work this way, each commit is expected to be able to land independently.
      - datsci_est_2015 2mo ago
        Doesn’t sound like it leaves much room for error. How do you address PR / MR comments? Force push?
Kinrany 2mo ago
Is it compatible with jujutsu?
- joaoqalves 2mo ago
  I'm not familiar with jujutsu. Maiao is fully git-compatible and the idea is to a) Not create new API/commands on top of it. Everything works with the normal "git commit". b) Progressively enhance the user experience. Each commit becomes a PR stacked atop each other. It auto-rebases if the base changes, and so on.
  - adastra22 2mo ago
    Probably worth looking into. It provides most of the machinery here on the version control side.
  - phatskat 2mo ago
    jj is a pretty nifty VCS - certainly worth looking in to. A lot of the concepts run parallel to Maiao I _think_, I'm still learning jujitsu myself. A couple questions: 1) what's the name about? 2) does this get wicked messy if I'm the only one on my team using Maiao?
    - joaoqalves 2mo ago
      1. It's explained in the README [1]. Tl;dr: Maiao is a "remote, sparsely populated volcanic atoll in French Polynesia" 2. I don't think so. The main difference from maiao to other stacked diffs projects is that it _progressively enhances_ GitHub. At the end of the day you just get PRs with branch #3 -> branch #2 -> branch #1 -> main. So, a bit of automation and rebases to do this. Because teams rarely can choose their forge, the intent is to not force org-wide change — e.g., change the VCS to jj — nor introduce more API/UI surface. You can be the only one doing stacked diffs in your team. Nothing breaks. 1 - https://github.com/runetes/maiao/#why-maiao https://github.com/runetes/maiao/#why-maiao
      - VulgarExigency 2mo ago
dolmen 2mo ago
The repo seems to move from "adevinta" (a well known company in the EU tech) to "runetes". Anyone to tell us the story?
- opello 2mo ago
  > Note: This is a community fork of adevinta/maiao. The original maintainers are no longer at Adevinta and the upstream repository is no longer actively maintained. This fork continues development under runetes/maiao.
- joaoqalves 2mo ago
  Hi! One of maiao's maintainers here, and ex-Adevinta. tl;dr: Adevinta got bought by a Private Equity consortium [1]. Since then, the fund did many changes, and layoffs. All of the original creators/maintainers don't work there anymore. Runetes is just an umbrella org for some OSS we created there. 1 - https://adevinta.com/press-releases/permira-and-blackstone-announce-voluntary-offer-for-all-outstanding-ordinary-class-a-shares-in-adevinta-at-nok-115-per-share/ https://adevinta.com/press-releases/permira-and-blackstone-a...
ppljudge 2mo ago
This sounds intriguing. Additionally, I wanted the community to evolve our approach to providing PR feedback. One of the unintended consequences was that it became a tool for people to exploit their workers.
- gojogs 2mo ago
  how so?
globular-toast 2mo ago
IME juniors struggle with making single commits in the first place. What I usually see is a scatter brained approach with more "fix" commits than anything else. This doesn't help with that, does it?
- peanball 2mo ago
  It could help in the sense that people would not accept a pile of `fix`, `fix of fix` commits in a PR anymore. The current UIs don't punish you for that as the reviewer mostly sees one final coherent change.
  - globular-toast 2mo ago
    I'm not aware of any PR/MR UI that hides the underlying commits. Some of us do look at them.
- bjackman 2mo ago
  It means you can comment on the problematic commits saying "please squash this". Then (if it works as well as Gerrit) you can compare the commit between the before and after squash state. Basically it lets you treat the commits as part of the thing you are reviewing instead of just a minor detail that the UI doesn't care about very much.
- Orphis 2mo ago
  The Juniors are also very good with AI. Having them merge bad commits into logical ones is a fine operation for them too.
andai 2mo ago
Maiao is based on Gerrit What's a Gerrit? (Looks it up) Gerrit is based on Rietveld What's a Rietveld? (Looks it up) Rietvelt integrates with SVN https://xkcd.com/178/ https://xkcd.com/178/
dizhn 2mo ago
Ton of questions asked that are answered on the posted page including the history of the fork and the meaning of the name. Guys your fellow users are not Gemini.
nh2 2mo ago
Code review tools should really compare with reviewable.io, which supports proper review of every-commit in a PR, with force pushes, making sure all changes get read, and comment sign-off and disposition, making sure no comment remains unaddressed. In contrast to Gerrit and Phabricator, it needs not "Change IDs" inserted in your commits (easier workflow just using git) and "just works" to review whole branches. It seems to me that "1 PR = 1 commit = 1 review" and "stacked PRs" workflows are just workarounds for not properly having implemented that as Reviewable has. Am I not seeing something? Reviewable's main drawback is being for Github only and not open source.
- fooqux 2mo ago
  Help me understand why I care about reviewing the fifteen commits my junior developer did while figuring out how to make a SQL query, and not just the final line of code? Typically, all I really care about is what's actually going into production, not the journey they took to get there. So, what am I missing?
  - jdub 2mo ago
    Those would be squashed into one commit. Then, when your senior developer is working on a new feature that requires some changes to adapt to a dependency upgrade, some refactoring, some forwards-and-backwards compatible database migrations, you'll appreciate a stack of discrete, clean, working, individually reviewable commits.
  - mtlynch 2mo ago
    > So, what am I missing? Gerrit/CodeApprove/Reviewable-style reviews are actually designed for exactly the scenario you're describing. The thing you're missing is that it's helpful to see a diff view of, "What changed since my last review?" If your review workflow is: 1. Junior engineer makes 15 commits to implement a feature in 300 LOC 2. Junior engineer sends you the PR for review 3. You review and send your notes to the engineer 4. Junior engineer makes 15 more commits and another 100 LOC churn, but PR is 350 LOC total diffs At (4), the thing you probably want to see are the 100 LOC of diffs since step (3). I haven't tried this on GitHub for awhile, but last I checked, your options are to either view only diff of PR against main branch, view each of the 15 commits individually, or hand edit the URL to get the "what's changed since (3)?" view. On Gerrit/CodeApprove/Reviewable, they all default to "what changed since I last reviewed?" and you comment on that diff rather than what's changed against the main branch, which is the default on GitHub.
perarneng 2mo ago
as someone who used Gerrit for a year: No
- sgerenser 2mo ago
  As someone who used Gerrit/still uses Gerrit for more than 3 years... also no.
felixlu2026 2mo ago
[dead]
synergy20 2mo ago
dumb question,why this and even gerrit? github or gitea PR seems much simpler and get the job done well these days
- fooqux 2mo ago
  Different strokes for different teams. Team size, project size, monolithic or not, etc. can all influence this. I'll say from personal experience that Gerrit helped my team a lot, if for no other reason than enforcing a "one commit equals one change" model. Also, the commenting and reviewing experience was liked more in Gerrit than Github.
binarin 1mo ago
Sadly doesn't work with git worktrees at all. (As a side note, this is not the first time I observe where go-git and worktrees don't play along nicely).

114 points by zdw 2mo ago

Does it use Github's new stacked PR feature? Edit: apparently stacked PRs on GH are older than I thought; the readme references a 2024 blog post about it.

dietr1ch 2mo ago
It seems so, https://github.com/runetes/maiao#quick-example https://github.com/runetes/maiao#quick-example As they say in mtg, reading the card explains the card
joaoqalves 2mo ago
Hi! Maintainer here. In short: maiao supported stacked PRs on GH, before it existed as a feature :) Now that it's exists (beta), it simply does "progressive enhancement" and adds the PRs to the native stack. But you could still perfectly function without it. That's how maiao works on Codeberg, and Bitbucket, for instance. GiLab has an interesting approach where they auto-stack up until 20 Merge Requests, if they're chained.

martythemaniak 2mo ago

Gerrit. Now that's a name I've not heard in a long time. A long time

jasonlotito 2mo ago

As someone who much prefers Gerrit's UI/UX over GitHub's UI, I was disappointed that this wasn't replicating the UI for GH reviews. Edit: Just to be clear, this is not a blemish on this project. More a lament and a wish someone would create such a thing for those of us forced to leave Gerrit behind for... GitHub. =/

joaoqalves 2mo ago
Hi! Maintainer here :) I think some projects already try that. The main goal of maiao is to progressively enhance GitHub with stacked PRs (1 commit = 1 PR) and create as little new API/UI surface as possible. That's why we don't have a `maiao new stack` command. Everything just runs atop normal git with a bit of `git rebase` and automation around GitHub's API. I hope it clarifies the intent.

NamlchakKhandro 2mo ago

Who is creating a separate PR for each commit on their feature/fix branch? sounds like crazy town. I just dont understand why someone would operate like this. Lets assume you're squash merging your feature branchs to your local main, then you're raising the them as prs. why would you do this?

steveklabnik 2mo ago
This is standard practice in the "stacked diffs" world: one review, one commit.
jsphweid 2mo ago
1 commit == 1 reviewable unit == 1 PR == 1 CL == 1 feature == 1 fix is a perfectly reasonable way of working. I used to work at companies where no one squashed their commits and the entire git logs were filled with 80% non-sense like "temp" or "bad" or "working" with the other 20% being coherent changes. What's the point of doing this I ask?
- cobalt 2mo ago
  it lets you maintain version history when working, then most workflows auto squash on merge
- datsci_est_2015 2mo ago
  Well are we talking about commits pre- or post-merge? I don’t care how many commits you put into the PR / MR as long as they squash down to a single commit upon merge.
  - steveklabnik 2mo ago
    When you work this way, each commit is expected to be able to land independently.
    - datsci_est_2015 2mo ago
      Doesn’t sound like it leaves much room for error. How do you address PR / MR comments? Force push?

Kinrany 2mo ago

Is it compatible with jujutsu?

joaoqalves 2mo ago
I'm not familiar with jujutsu. Maiao is fully git-compatible and the idea is to a) Not create new API/commands on top of it. Everything works with the normal "git commit". b) Progressively enhance the user experience. Each commit becomes a PR stacked atop each other. It auto-rebases if the base changes, and so on.
- adastra22 2mo ago
  Probably worth looking into. It provides most of the machinery here on the version control side.
- phatskat 2mo ago
  jj is a pretty nifty VCS - certainly worth looking in to. A lot of the concepts run parallel to Maiao I _think_, I'm still learning jujitsu myself. A couple questions: 1) what's the name about? 2) does this get wicked messy if I'm the only one on my team using Maiao?
  - joaoqalves 2mo ago
    1. It's explained in the README [1]. Tl;dr: Maiao is a "remote, sparsely populated volcanic atoll in French Polynesia" 2. I don't think so. The main difference from maiao to other stacked diffs projects is that it _progressively enhances_ GitHub. At the end of the day you just get PRs with branch #3 -> branch #2 -> branch #1 -> main. So, a bit of automation and rebases to do this. Because teams rarely can choose their forge, the intent is to not force org-wide change — e.g., change the VCS to jj — nor introduce more API/UI surface. You can be the only one doing stacked diffs in your team. Nothing breaks. 1 - https://github.com/runetes/maiao/#why-maiao https://github.com/runetes/maiao/#why-maiao
    - VulgarExigency 2mo ago

dolmen 2mo ago

The repo seems to move from "adevinta" (a well known company in the EU tech) to "runetes". Anyone to tell us the story?

opello 2mo ago
> Note: This is a community fork of adevinta/maiao. The original maintainers are no longer at Adevinta and the upstream repository is no longer actively maintained. This fork continues development under runetes/maiao.
joaoqalves 2mo ago
Hi! One of maiao's maintainers here, and ex-Adevinta. tl;dr: Adevinta got bought by a Private Equity consortium [1]. Since then, the fund did many changes, and layoffs. All of the original creators/maintainers don't work there anymore. Runetes is just an umbrella org for some OSS we created there. 1 - https://adevinta.com/press-releases/permira-and-blackstone-announce-voluntary-offer-for-all-outstanding-ordinary-class-a-shares-in-adevinta-at-nok-115-per-share/ https://adevinta.com/press-releases/permira-and-blackstone-a...

ppljudge 2mo ago

This sounds intriguing. Additionally, I wanted the community to evolve our approach to providing PR feedback. One of the unintended consequences was that it became a tool for people to exploit their workers.

gojogs 2mo ago
how so?

globular-toast 2mo ago

IME juniors struggle with making single commits in the first place. What I usually see is a scatter brained approach with more "fix" commits than anything else. This doesn't help with that, does it?

peanball 2mo ago
It could help in the sense that people would not accept a pile of `fix`, `fix of fix` commits in a PR anymore. The current UIs don't punish you for that as the reviewer mostly sees one final coherent change.
- globular-toast 2mo ago
  I'm not aware of any PR/MR UI that hides the underlying commits. Some of us do look at them.
bjackman 2mo ago
It means you can comment on the problematic commits saying "please squash this". Then (if it works as well as Gerrit) you can compare the commit between the before and after squash state. Basically it lets you treat the commits as part of the thing you are reviewing instead of just a minor detail that the UI doesn't care about very much.
Orphis 2mo ago
The Juniors are also very good with AI. Having them merge bad commits into logical ones is a fine operation for them too.

andai 2mo ago

Maiao is based on Gerrit What's a Gerrit? (Looks it up) Gerrit is based on Rietveld What's a Rietveld? (Looks it up) Rietvelt integrates with SVN https://xkcd.com/178/ https://xkcd.com/178/

dizhn 2mo ago

Ton of questions asked that are answered on the posted page including the history of the fork and the meaning of the name. Guys your fellow users are not Gemini.

nh2 2mo ago

Code review tools should really compare with reviewable.io, which supports proper review of every-commit in a PR, with force pushes, making sure all changes get read, and comment sign-off and disposition, making sure no comment remains unaddressed. In contrast to Gerrit and Phabricator, it needs not "Change IDs" inserted in your commits (easier workflow just using git) and "just works" to review whole branches. It seems to me that "1 PR = 1 commit = 1 review" and "stacked PRs" workflows are just workarounds for not properly having implemented that as Reviewable has. Am I not seeing something? Reviewable's main drawback is being for Github only and not open source.

fooqux 2mo ago
Help me understand why I care about reviewing the fifteen commits my junior developer did while figuring out how to make a SQL query, and not just the final line of code? Typically, all I really care about is what's actually going into production, not the journey they took to get there. So, what am I missing?
- jdub 2mo ago
  Those would be squashed into one commit. Then, when your senior developer is working on a new feature that requires some changes to adapt to a dependency upgrade, some refactoring, some forwards-and-backwards compatible database migrations, you'll appreciate a stack of discrete, clean, working, individually reviewable commits.
- mtlynch 2mo ago
  > So, what am I missing? Gerrit/CodeApprove/Reviewable-style reviews are actually designed for exactly the scenario you're describing. The thing you're missing is that it's helpful to see a diff view of, "What changed since my last review?" If your review workflow is: 1. Junior engineer makes 15 commits to implement a feature in 300 LOC 2. Junior engineer sends you the PR for review 3. You review and send your notes to the engineer 4. Junior engineer makes 15 more commits and another 100 LOC churn, but PR is 350 LOC total diffs At (4), the thing you probably want to see are the 100 LOC of diffs since step (3). I haven't tried this on GitHub for awhile, but last I checked, your options are to either view only diff of PR against main branch, view each of the 15 commits individually, or hand edit the URL to get the "what's changed since (3)?" view. On Gerrit/CodeApprove/Reviewable, they all default to "what changed since I last reviewed?" and you comment on that diff rather than what's changed against the main branch, which is the default on GitHub.

perarneng 2mo ago

as someone who used Gerrit for a year: No

sgerenser 2mo ago
As someone who used Gerrit/still uses Gerrit for more than 3 years... also no.

felixlu2026 2mo ago

[dead]

synergy20 2mo ago

dumb question,why this and even gerrit? github or gitea PR seems much simpler and get the job done well these days

fooqux 2mo ago
Different strokes for different teams. Team size, project size, monolithic or not, etc. can all influence this. I'll say from personal experience that Gerrit helped my team a lot, if for no other reason than enforcing a "one commit equals one change" model. Also, the commenting and reviewing experience was liked more in Gerrit than Github.

binarin 1mo ago

Sadly doesn't work with git worktrees at all. (As a side note, this is not the first time I observe where go-git and worktrees don't play along nicely).