Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

41–50 of 68 posts

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

#41

Post by phatskat »

joaoqalves wrote: post #34
Kinrany wrote: post #15

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.

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?

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

#42

Post by joaoqalves »

phatskat wrote: post #41
joaoqalves wrote: post #34

Earlier quoted context omitted.

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.

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?

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

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

#43

Post by adrian_m »

jsphweid wrote: post #8
NamlchakKhandro wrote: post #6

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?

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?

I don’t quite get the situation. After merging a PR/MR (with the squash feature of Gitlab or GitHub) the equality you describe holds and there’s a nice sequential git log.

I quite like that I can tell my colleagues they can commit whenever they feel like it (and should probably commit more often than they feel like) because it becomes one clean commit in the end anyways.

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

#45

Post by boomlinde »

chrisweekly wrote: post #12
what wrote: post #9

Earlier quoted context omitted.

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…

In Gerrit, I would say that the equivalent of the epic is the topic, stacks are the stories and commits are the tasks.

It certainly puts pressure on the scope and quality of commits, but I think that's only undue for a short-lived project where you don't foresee a long period of maintenance. Consistently high quality commits with a clear scope is a godsend when you are investigating the history of a project. Some small pressure now is IMO better than greater pressure later when you are debugging an issue at three in the morning and scrolling through either a bunch of "fix stuff" commits or 1000+ line PR squashes.

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

#46

Post by nh2 »

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.

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

#48

Post by mejutoco »

chrisweekly wrote: post #12
what wrote: post #9

Earlier quoted context omitted.

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…

> 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

You can do as many commits as you want locally. Then go back and squash them before pushing. I think that addresses all your points, if I am not mistaken.

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

#49

Post by VulgarExigency »

joaoqalves wrote: post #42
phatskat wrote: post #41

Earlier quoted context omitted.

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?

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 thei…

jj can work with git as its storage, so all of its commits are git commits, so a jj-local and git-remote flow is fully supported. I use it, and as far as I know I'm the only one on my team doing so.

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

#50

Post by boomlinde »

adrian_m wrote: post #43
jsphweid wrote: post #8

Earlier quoted context omitted.

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?

I don’t quite get the situation. After merging a PR/MR (with the squash feature of Gitlab or GitHub) the equality you describe holds and there’s a nice sequential git log. I quite like that I can tell my colleagues they can commit whenever they feel like it (and should probably commit more often than they feel like) because it becomes one clean commit in the end anyways.

In my experience the situation with GitHub is either that

- you apply the commits as-is on the target branch and end up with a ton of pointless "fix this" and "fix that" commits that were created during the review process,

- you squash everything and lose what might otherwise have been meaningful, useful commit boundaries for the purpose of bisecting, reverting or just investigating the history of changes or

- you rework your commits and force push changes to the branch you want to pull and create confusion as to what changed because that's not usually how review is conducted with GitHub.

I think the pull request is a bad abstraction. Not terrible, and certainly easy to grasp, but bad enough that everything you do with it is a compromise. At the very best, if you apply with the squash+rebase strategy and limit the scope of your PRs to what makes perfect sense as just one commit in the target branch, it's just a convoluted way of working with individual commits.

Post reply on HN