Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
1–10 of 71 posts
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#2Does 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.
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#3Gerrit. Now that's a name I've not heard in a long time. A long time
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#4Does 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.
It seems so, https://github.com/runetes/maiao#quick-example
As they say in mtg, reading the card explains the card
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#5As 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. =/
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#6Who 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?
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#7Who 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.
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#8Who 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?
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?
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#9Who 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?
Why would you have more than one commit for a PR? That sounds like crazy town.
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#10Who 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?
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.