Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
55 points - yesterday at 10:40 PM
SourceThis 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.
globular-toast
today at 5:40 AM
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 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.
The repo seems to move from "adevinta" (a well known company in the EU tech) to "runetes". Anyone to tell us the story?
> 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.
Is it compatible with jujutsu?
NamlchakKhandro
today at 1:37 AM
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?
shubhamjain
today at 5:48 AM
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.
On large teams I think the "cherry pick" workflow (Gerrit style) beats the "pull request" workflow (GitHub/gitlab style). On smaller teams it's the other way around. I think it's somewhere around 10-20 people actively committing that the cherry pick workflow comes out ahead.
danpalmer
today at 4:02 AM
This is exactly it. When I worked in a ~10 person team I just didn't get it, PRs worked quite well (with some basic discipline, they're not perfect). When I moved to a... much larger company... I don't know how PRs would work here, it would be way too unwieldy. The Gerrit style works fantastically here.
steveklabnik
today at 1:39 AM
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?
datsci_est_2015
today at 2:38 AM
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
today at 2:57 AM
When you work this way, each commit is expected to be able to land independently.
it lets you maintain version history when working, then most workflows auto squash on merge
Why would you have more than one commit for a PR? That sounds like crazy town.
chrisweekly
today at 2:26 AM
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)?".
If your PR has more than one commit, each one should be deployable in isolation. Which means you can split your giant PR into smaller ones that can be reviewed independently.
I’ve worked under both systems, but isn’t the purity you’re describing a bit of a dodge in that you wind up force pushing amended commits when you find you forgot something?
adastra22
today at 5:31 AM
Not once they hit master, no. You push bug fix commits.
steveklabnik
today at 3:33 AM
Why is that a dodge? that's the expected way to work in this system, and it should be able to show you the interdiff between those amends.
jasonlotito
today at 1:25 AM
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. =/
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.
martythemaniak
today at 12:50 AM
Gerrit. Now that's a name I've not heard in a long time. A long time