[dead]
Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
51–60 of 72 posts
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#52Code 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 se…
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?
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#53Earlier quoted context omitted.
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.
Doesn’t sound like it leaves much room for error. How do you address PR / MR comments? Force push?
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#54Code 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 se…
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?
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.
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#55dumb question,why this and even gerrit? github or gitea PR seems much simpler and get the job done well these days
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#56as someone who used Gerrit for a year: No
As someone who used Gerrit/still uses Gerrit for more than 3 years... also no.
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#57dumb question,why this and even gerrit? github or gitea PR seems much simpler and get the job done well these days
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.
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#58Code 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 se…
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?
> 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.
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#59Earlier quoted context omitted.
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?
> 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…
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.
Re: Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others
#60Is 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.
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.