Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Gerrit. Now that's a name I've not heard in a long time. A long time
    by martythemaniak
  • as someone who used Gerrit for a year: No
    by perarneng
  • As someone who used Gerrit/still uses Gerrit for more than 3 years... also no.
    by sgerenser
  • 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.
    by dizhn
  • 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.
    by ppljudge
  • how so?
    by gojogs
  • dumb question,why this and even gerrit? github or gitea PR seems much simpler and get the job done well these days
    by synergy20
  • 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.

    by fooqux
  • 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.

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

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

    by dietr1ch
  • 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.

    by joaoqalves
  • 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?
    by globular-toast
  • The Juniors are also very good with AI. Having them merge bad commits into logical ones is a fine operation for them too.
    by Orphis
  • 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.

    by peanball
  • 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.

    by bjackman
  • 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).
    by binarin
  • Is it compatible with jujutsu?
    by Kinrany
  • 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.

    by joaoqalves
  • 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?

    by NamlchakKhandro
  • You wouldn't. Imagine you have more than one of what you are calling a "feature/fix branch" and they depend on each other.
    by IshKebab
  • Why would you have more than one commit for a PR? That sounds like crazy town.
    by what
  • 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.

    by shubhamjain
  • 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?

    by jsphweid
  • This is standard practice in the "stacked diffs" world: one review, one commit.
    by steveklabnik
  • It makes every commit small, so they can be reviewed quickly and easily.

    Small commits can often be tested faster, since irrelevant tests don't need to run.

    Small commits are less risky. The smaller the delta of change, the lower the probability that something breaks.

    Small commits get merged sooner; big commits take time to build up. Merging early front-loads your integration risk; merging later puts integration risk just before delivery.

    Breaking a big feature into small commits means using feature flags to control whether a feature is enabled or not (since control paths will generally be incomplete). This means you separate the delivery of the code from the delivery of the feature, and has the added benefit that you can turn off a feature that has a problematic rollout without needing to redeploy code.

    by barrkel
  • 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.
    by verall
  • The repo seems to move from "adevinta" (a well known company in the EU tech) to "runetes". Anyone to tell us the story?
    by dolmen
  • 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-a...

    by joaoqalves
  • > 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.
    by opello
  • 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. =/

    by jasonlotito