Rendered at 19:30:44 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
dolmen 17 hours ago [-]
The repo seems to move from "adevinta" (a well known company in the EU tech) to "runetes". Anyone to tell us the story?
opello 14 hours ago [-]
> 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.
joaoqalves 13 hours ago [-]
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.
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.
barrkel 6 hours ago [-]
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.
cabyambo 4 hours ago [-]
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
Kinrany 2 hours ago [-]
Does it let you manually keep track of the parts you've actually seen? Instead of using the granularity provided by the PR author?
cabyambo 1 hours ago [-]
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.
dijit 6 hours ago [-]
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 terms relevant for this thread, jujutsu is a git CLI with much better UX and support for change IDs. Most history editing operations become trivial. Code review and PR management should be a much thinner layer if implemented on top of jujutsu.
Personally, I think jujutsu has already succeeded at becoming a "git killer" in terms of UX and adoption. It is compatible with git, so I'm never going back to using git directly.
phatskat 12 hours ago [-]
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?
joaoqalves 11 hours ago [-]
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.
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
VulgarExigency 10 hours ago [-]
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.
barrkel 6 hours ago [-]
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.
adastra22 12 hours ago [-]
Probably worth looking into. It provides most of the machinery here on the version control side.
synergy20 8 hours ago [-]
dumb question,why this and even gerrit? github or gitea PR seems much simpler and get the job done well these days
fooqux 8 hours ago [-]
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.
perarneng 10 hours ago [-]
as someone who used Gerrit for a year: No
sgerenser 8 hours ago [-]
As someone who used Gerrit/still uses Gerrit for more than 3 years... also no.
ppljudge 14 hours ago [-]
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.
gojogs 14 hours ago [-]
how so?
jasonlotito 18 hours ago [-]
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. =/
joaoqalves 12 hours ago [-]
Hi! Maintainer here :) I think some projects already try that. The main goal of maiao is to progressively enhance GitHub with stacked PRs (1 commit = 1 PR) and create as little new API/UI surface as possible. That's why we don't have a `maiao new stack` command. Everything just runs atop normal git with a bit of `git rebase` and automation around GitHub's API. I hope it clarifies the intent.
globular-toast 14 hours ago [-]
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?
bjackman 13 hours ago [-]
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.
peanball 14 hours ago [-]
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.
globular-toast 13 hours ago [-]
I'm not aware of any PR/MR UI that hides the underlying commits. Some of us do look at them.
Orphis 12 hours ago [-]
The Juniors are also very good with AI. Having them merge bad commits into logical ones is a fine operation for them too.
NamlchakKhandro 18 hours ago [-]
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?
barrkel 6 hours ago [-]
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.
verall 17 hours ago [-]
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.
danpalmer 15 hours ago [-]
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.
steveklabnik 18 hours ago [-]
This is standard practice in the "stacked diffs" world: one review, one commit.
shubhamjain 14 hours ago [-]
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.
jsphweid 18 hours ago [-]
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?
l72 4 hours ago [-]
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.
adrian_m 11 hours ago [-]
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.
boomlinde 9 hours ago [-]
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.
zmmmmm 13 hours ago [-]
there is an inbetween .... i insist people interactively rebase those commits out. In some contexts it is actually important to have traceability of iterative proof of work towards the final result.
datsci_est_2015 17 hours ago [-]
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.
steveklabnik 17 hours ago [-]
When you work this way, each commit is expected to be able to land independently.
datsci_est_2015 9 hours ago [-]
Doesn’t sound like it leaves much room for error. How do you address PR / MR comments? Force push?
steveklabnik 3 hours ago [-]
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.
cobalt 17 hours ago [-]
it lets you maintain version history when working, then most workflows auto squash on merge
what 18 hours ago [-]
Why would you have more than one commit for a PR? That sounds like crazy town.
chrisweekly 17 hours ago [-]
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)?".
boomlinde 11 hours ago [-]
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.
mejutoco 10 hours ago [-]
> 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.
what 17 hours ago [-]
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.
tclancy 16 hours ago [-]
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?
Orphis 12 hours ago [-]
People say they care about the "story" behind the PR. But no one cares about that story if it's about forgetting to fix a test and a typo in a comment.
The extra commits are just noise that make you think the original commit is a source of truth in a blame when it has been amended 3 times more in the same PR, but the link isn't apparent anymore.
Force pushing is bad to a published branch, not a feature branch (not that you really have force pushes in Gerrit anyway). There are versions of Gerrit tooling where you can have a branch as dirty as you want locally, but only the final aggregated change is visible for review of that's what you prefer too.
steveklabnik 16 hours ago [-]
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.
tclancy 50 minutes ago [-]
Sorry, “dodge” was a loaded word. I suppose what I mean is, what’s the difference between a PR with multiple commits and a commit with multiple commits?
adastra22 14 hours ago [-]
Not once they hit master, no. You push bug fix commits.
dbetteridge 12 hours ago [-]
A PR is a collection of commits?
Integration into main ideally is squashed down to a single merge commit though.
It shouldn't matter how many commits a pr takes to from 0 to finished
IshKebab 12 hours ago [-]
You wouldn't. Imagine you have more than one of what you are calling a "feature/fix branch" and they depend on each other.
esafak 19 hours ago [-]
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.
joaoqalves 13 hours ago [-]
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.
As they say in mtg, reading the card explains the card
dizhn 11 hours ago [-]
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.
martythemaniak 19 hours ago [-]
Gerrit. Now that's a name I've not heard in a long time. A long time
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.
fooqux 9 hours ago [-]
Help me understand why I care about reviewing the fifteen commits my junior developer did while figuring out how to make a SQL query, and not just the final line of code? Typically, all I really care about is what's actually going into production, not the journey they took to get there. So, what am I missing?
mtlynch 7 hours ago [-]
> So, what am I missing?
Gerrit/CodeApprove/Reviewable-style reviews are actually designed for exactly the scenario you're describing.
The thing you're missing is that it's helpful to see a diff view of, "What changed since my last review?"
If your review workflow is:
1. Junior engineer makes 15 commits to implement a feature in 300 LOC
2. Junior engineer sends you the PR for review
3. You review and send your notes to the engineer
4. Junior engineer makes 15 more commits and another 100 LOC churn, but PR is 350 LOC total diffs
At (4), the thing you probably want to see are the 100 LOC of diffs since step (3). I haven't tried this on GitHub for awhile, but last I checked, your options are to either view only diff of PR against main branch, view each of the 15 commits individually, or hand edit the URL to get the "what's changed since (3)?" view.
On Gerrit/CodeApprove/Reviewable, they all default to "what changed since I last reviewed?" and you comment on that diff rather than what's changed against the main branch, which is the default on GitHub.
fooqux 7 hours ago [-]
Ah, if true, than I misunderstood and agree. That didn't sound like what the person I replied to was saying though.
It's hard to leave Gerrit after using it.
jdub 8 hours ago [-]
Those would be squashed into one commit.
Then, when your senior developer is working on a new feature that requires some changes to adapt to a dependency upgrade, some refactoring, some forwards-and-backwards compatible database migrations, you'll appreciate a stack of discrete, clean, working, individually reviewable commits.
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...
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.
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.
There are also the "Mark as reviewed" checkboxes per file that can help you track what's been looked at.
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/
Personally, I think jujutsu has already succeeded at becoming a "git killer" in terms of UX and adoption. It is compatible with git, so I'm never going back to using git directly.
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?
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
Very cool stuff, will be trying it out
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.
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. =/
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.
The current UIs don't punish you for that as the reviewer mostly sees one final coherent change.
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?
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.
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.
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?
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.
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.
- 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.
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.
It's equivalent to asking, "Why would you have more than one story in an epic (or task in a story)?".
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.
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.
The extra commits are just noise that make you think the original commit is a source of truth in a blame when it has been amended 3 times more in the same PR, but the link isn't apparent anymore.
Force pushing is bad to a published branch, not a feature branch (not that you really have force pushes in Gerrit anyway). There are versions of Gerrit tooling where you can have a branch as dirty as you want locally, but only the final aggregated change is visible for review of that's what you prefer too.
Integration into main ideally is squashed down to a single merge commit though.
It shouldn't matter how many commits a pr takes to from 0 to finished
Edit: apparently stacked PRs on GH are older than I thought; the readme references a 2024 blog post about it.
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.
As they say in mtg, reading the card explains the card
What's a Gerrit? (Looks it up)
Gerrit is based on Rietveld
What's a Rietveld? (Looks it up)
Rietvelt integrates with SVN
https://xkcd.com/178/
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.
Gerrit/CodeApprove/Reviewable-style reviews are actually designed for exactly the scenario you're describing.
The thing you're missing is that it's helpful to see a diff view of, "What changed since my last review?"
If your review workflow is:
1. Junior engineer makes 15 commits to implement a feature in 300 LOC
2. Junior engineer sends you the PR for review
3. You review and send your notes to the engineer
4. Junior engineer makes 15 more commits and another 100 LOC churn, but PR is 350 LOC total diffs
At (4), the thing you probably want to see are the 100 LOC of diffs since step (3). I haven't tried this on GitHub for awhile, but last I checked, your options are to either view only diff of PR against main branch, view each of the 15 commits individually, or hand edit the URL to get the "what's changed since (3)?" view.
On Gerrit/CodeApprove/Reviewable, they all default to "what changed since I last reviewed?" and you comment on that diff rather than what's changed against the main branch, which is the default on GitHub.
It's hard to leave Gerrit after using it.
Then, when your senior developer is working on a new feature that requires some changes to adapt to a dependency upgrade, some refactoring, some forwards-and-backwards compatible database migrations, you'll appreciate a stack of discrete, clean, working, individually reviewable commits.