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

61–70 of 72 posts

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

#61

Post by phatskat »

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…

Thanks! Sorry about 1, I was worried I had missed it in the readme, I was hopping all over the docs pages before coming back to the post lol

Very cool stuff, will be trying it out

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

#62

Post by barrkel »

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.

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.

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

#63

Post by barrkel »

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 support doesn't force an org-wide change. jj is compatible with git. It's just that the mental model is more aligned to Gerrit and stacked PRs.

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

#64

Post by barrkel »

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?

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.

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

#65

Post by dijit »

barrkel wrote: post #62
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.

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

I should probably post my guide on how to use gerrit and JJ together nicely.

I wrote it internally after struggling a lot with getting the relevant knowledge from the relevant authorities (Klabnik has the best resources but his writing seems to depend on you understanding abstract concepts before you grasp the practicality, which works for programming languages but less so for tools - which you want to "get out of the way").

in fact.. screw it... here: https://blog.dijit.sh/gerrit_with_jj/

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

#66

Post by cabyambo »

barrkel wrote: post #62
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.

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

I agree. Mutable commits are making a comeback recently and I love it. A hill I'll also die on is that branches shouldn't exist lol. Disclaimer - I'm the founder - but if you want a review tool that caters to jj users you might like revset.dev. It shows you the jj commits that make up a PR, and you can see the various revisions the jj commits and PR have gone through

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

#67

Post by l72 »

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 wish git worked like some of the other dvcs (bazaar/breezy). The default merge type from a branch should be a merge commit and git log should only show the first parent (commits directly on the current branch).

This gives you a very clean log on main (it only shows commits directly on this branch). There is no need to squash, rebase, or anything else. And if you want to dig down into individual commits that happened on a branch, you can!

This can be a bit replicated by forcing a merge type of merge and setting an alias of log to "log --first-parent", but since that isn't the default, that isn't what you see when you look at the commit logs on platforms like github.

I never understood why git decided to show a flat list of every commit that happened, even if the commit originally happened on a separate branch.

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

#68

Post by steveklabnik »

datsci_est_2015 wrote: post #53
steveklabnik wrote: post #17

Earlier quoted context omitted.

When you work this way, each commit is expected to be able to land independently.

Doesn’t sound like it leaves much room for error. How do you address PR / MR comments? Force push?

The reason people like to work this way is that it lets you very effectively respond to review. You address them by amending the commit to incorporate the feedback.

This enables good interdiff review, so you can re-review just the new stuff in the new version of the commit and not the entire thing all over again.

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

#69

Post by Kinrany »

cabyambo wrote: post #66
barrkel wrote: post #62

Earlier quoted context omitted.

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

I agree. Mutable commits are making a comeback recently and I love it. A hill I'll also die on is that branches shouldn't exist lol. Disclaimer - I'm the founder - but if you want a review tool that caters to jj users you might like revset.dev. It shows you the jj commits that make up a PR, and you can see the various revisions the jj commits and PR have gone through

Does it let you manually keep track of the parts you've actually seen? Instead of using the granularity provided by the PR author?

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

#70

Post by cabyambo »

Kinrany wrote: post #69
cabyambo wrote: post #66

Earlier quoted context omitted.

I agree. Mutable commits are making a comeback recently and I love it. A hill I'll also die on is that branches shouldn't exist lol. Disclaimer - I'm the founder - but if you want a review tool that caters to jj users you might like revset.dev. It shows you the jj commits that make up a PR, and you can see the various revisions the jj commits and PR have gone through

Does it let you manually keep track of the parts you've actually seen? Instead of using the granularity provided by the PR author?

It does. This is definitely something that's being actively iterated on though. Let's say as a reviewer you leave some comments on Revision 3, then the user pushes 2 more PR revisions and asks you to re-review. The default diff when you open the PR again will be from Revision 3 -> Current code. It lets reviewers easily see what's changed since their last review.

There are also the "Mark as reviewed" checkboxes per file that can help you track what's been looked at.

Post reply on HN