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. =/

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

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?

This is standard practice in the "stacked diffs" world: one review, one commit.

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?

Loose commit histories also mess with bisect and blame in ways that get underappreciated. Fowler and others writing on trunk-based dev tend to assume atomic, meaningful commits precisely because tooling built on git history quietly depends on that discipline.

I haven’t used this project but I have used Gerrit. It has its drawbacks (like terrible UX) but its style of code reviews were the most sensible and commit of every PR might not be as bad as it sounds. GitHub’s PR reviews are atrocious and it’s unfortunate they have become the gold standard.

In Gerrit, you commit every review, and the author has to edit individual commits to address them (using git rebase). This may sound PITA but it makes the history absolutely clean, and makes it easier for both reviewers and authors to review and address suggestions.

On Github, on the other hand, reviewing a large PR is just insanely hard. Making sure comment was addressed properly is hard as well, they can get lost in a sea of suggestions. They also become separate commits instead of being part of the commit itself. The commit should always been treated as unit of work rather than the branch.

Gold standard just means most popular, not best.

Why would you have more than one commit for a PR? That sounds like crazy town.

IMHO equating commits and PRs puts undue pressure on the scope and quality of a given commit, adding potential for unnecessary stress and eliminating the benefits of an additional buffer / layer for aggregation of changes. A PR representing a sizable feature or refactor might naturally contain a dozen commits, each dedicated to a logical area or a requisite subset of the whole. Assuming on principle a goal of keeping main in a known-good state, such intermediate and incomplete changes (fine in an unstable feature branch) would wreak havoc.

It's equivalent to asking, "Why would you have more than one story in an epic (or task in a story)?".

A PR is a collection of commits?

Integration into main ideally is squashed down to a single merge commit though.

It shouldn't matter how many commits a pr takes to from 0 to finished

You wouldn't. Imagine you have more than one of what you are calling a "feature/fix branch" and they depend on each other.

Did this for years with Gerrit and later Phabricator. The trick nobody mentions: you don't create new commits per fix, you amend the same commit and force-push, so the PR/CL number stays stable while the diff updates. Comments anchor to lines, not commit SHAs. Breaks completely if your tooling assumes append-only history.

Is it compatible with jujutsu?

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.

Jujutsu has a mental model that aligns far more closely to Gerrit than GitHub etc.

It uses a persistent changeid to model a change mutating over time, like Gerrit uses Change-Id in the description footer, and unlike git.

Jujutsu can be colocated with git and use .git as its backing store; every jj change revision is a git commit.

When you use jujutsu, you tend not to use branches any more, and think in terms of changes and chains of changes (i.e. stacked PRs, what Gerrit calls Relation Chains).

Jujutsu makes it very easy to work with a chain of changes (stacked PRs), letting you update commits in the middle and automatically rebasing the rest of the chain, without forcing you to interrupt work and resolve conflicts if there happen to be any (so, unlike git rebase -i with 'edit' on the commit you want to update).

IMO if you like the Gerrit workflow and the way it handles chained commits, if you switch to jj for two days of work, you'll never want to use git again.

In terms relevant for this thread, jujutsu is a git CLI with much better UX and support for change IDs. Most history editing operations become trivial. Code review and PR management should be a much thinner layer if implemented on top of jujutsu.

Personally, I think jujutsu has already succeeded at becoming a "git killer" in terms of UX and adoption. It is compatible with git, so I'm never going back to using git directly.

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?

Probably worth looking into. It provides most of the machinery here on the version control side.

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).

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?

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.

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.

I'm not aware of any PR/MR UI that hides the underlying commits. Some of us do look at them.

The Juniors are also very good with AI. Having them merge bad commits into logical ones is a fine operation for them too.

Seen this at two startups. Tool won't fix habit, review culture does. We started rejecting PRs with "fix fix fix" history until squashed, took a month, juniors adjusted fast once it actually blocked merge instead of just being a suggestion.

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.

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.

It seems so, https://github.com/runetes/maiao#quick-example

As they say in mtg, reading the card explains the card

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

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.

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.

how so?

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.

as someone who used Gerrit for a year: No

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

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

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/

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.

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?

> 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.

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.

Used something similar for stacked PRs last year, biggest pain was always the commit-msg hook that injects the Change-Id trailer, if you squash or rebase wrong it orphans the tracking and you get duplicate PRs. Worth checking how this handles that before rolling it out to a team.