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

11–20 of 69 posts

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

#11

Post by cobalt »

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?

it lets you maintain version history when working, then most workflows auto squash on merge

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

#12

Post by chrisweekly »

what wrote: post #9
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?

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 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)?".

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

#13

Post by what »

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…

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.

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

#14

Post by datsci_est_2015 »

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?

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.

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

#17

Post by steveklabnik »

datsci_est_2015 wrote: post #14
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?

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.

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

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

#18

Post by tclancy »

what wrote: post #13
chrisweekly wrote: post #12

Earlier quoted context omitted.

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…

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?

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

#19

Post by steveklabnik »

tclancy wrote: post #18
what wrote: post #13

Earlier quoted context omitted.

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?

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.

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

#20

Post by danpalmer »

verall wrote: post #10
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?

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.

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.
Post reply on HN