3 ms·

Is there a good code review tool out there? The best one I've used is Gerrit, at least it has a sensible design in principle. Aside from that I've only used Git

Is there a good code review tool out there? The best one I've used is Gerrit, at least it has a sensible design in principle. Aside from that I've only used GitHub and Gitlab which both seem like toys to me. (And mailing lists, lol). But the implementation of Gerrit seems rather unloved, it just seems to get the minimal maintenance to keep Go/Android chooching along, and nothing more.

seabrookmx 8mo ago
My old job used Gerrit, and new job uses Gitlab. I really miss the information density and workflow of Gerrit. We enforce fast forward merges and squashing for MR's anyways, so we just have an awkward version of what Gerrit does by default. Gitlab CI is good but we use local (k8s-hosted) runners so I have to imagine there's a bunch of options that provide a similar experience.
- bjackman 8mo ago
  You can't "stack" MRs in Gitlab though right? So if you're merging a complex feature you just have one huge mega commit?
  - techcode 8mo ago
    What do you mean by "stack" MRs? Just like with plain git - in GitLab you can merge a branch that has multiple separate commits in it. And you can also merge (e.g. topical/feature) branches into one branch - and then merge that "combined" branch into main/master. Though most teams/project prefer you don't stretch that route to the extreme - simply because it's PITA to maintain/sync several branches for a long period of time, resolving merge conflicts between branches that have been separate for a long time isn't fun, and people don't like to review huge diffs.
    - bjackman 8mo ago
      I guess what I'm saying is: for very large complex features, I don't want one big commit. I want to review a series of commits and then I want to have that series of commits persist in the history. This is how Gerrit operates "natively" - the commit message and everything is part of the artifact under review exactly like the diff. If the model is to squash an MR into a single commit before merging it, I'd then want to be able to have MRs that depend on each other.
      - seabrookmx 8mo ago
        You can "chain" them and there's some native support for this in Gitlab, but I can't say I've ever tried using it. If I really need a feature branch, I just create a separate branch and target my MR's to that until the whole thing is ready to land in main. Again, it seems less natural to me than how Gerrit does it.
Intralexical 8mo ago
What do people think of ReviewBoard?
maccard 8mo ago
We use perforce in work, and we use p4 swarm. It’s unremarkable, hasn’t changed in a decade and just works. Best part of perforce, by far
jamesfinlayson 8mo ago
I miss Gerrit - it was the first code review tool I used at work. Using GitHub and GitLab as subsequent jobs hasn't been fun.
lima 8mo ago
> But the implementation of Gerrit seems rather unloved There are lots of people who are very fond of Gerrit, and if anything, upstream development has picked up recently. Google has an increasing amount of production code that lives outside of their monorepo, and all of those teams use Gerrit. They have a few internal plugins, but most improvements are released as part of the upstream project. My company has been using it for years, it's a big and sustained productivity win once everyone is past the learning curve. Gerritforge[0] offers commercial support and runs a very stable public instance, GerritHub. I'm not affiliated with them and not a customer, but I talk to them a lot on the Gerrit Discord server and they're awesome. [0]: https://www.gerritforge.com/ https://www.gerritforge.com/

seabrookmx 8mo ago

My old job used Gerrit, and new job uses Gitlab. I really miss the information density and workflow of Gerrit. We enforce fast forward merges and squashing for MR's anyways, so we just have an awkward version of what Gerrit does by default. Gitlab CI is good but we use local (k8s-hosted) runners so I have to imagine there's a bunch of options that provide a similar experience.

bjackman 8mo ago
You can't "stack" MRs in Gitlab though right? So if you're merging a complex feature you just have one huge mega commit?
- techcode 8mo ago
  What do you mean by "stack" MRs? Just like with plain git - in GitLab you can merge a branch that has multiple separate commits in it. And you can also merge (e.g. topical/feature) branches into one branch - and then merge that "combined" branch into main/master. Though most teams/project prefer you don't stretch that route to the extreme - simply because it's PITA to maintain/sync several branches for a long period of time, resolving merge conflicts between branches that have been separate for a long time isn't fun, and people don't like to review huge diffs.
  - bjackman 8mo ago
    I guess what I'm saying is: for very large complex features, I don't want one big commit. I want to review a series of commits and then I want to have that series of commits persist in the history. This is how Gerrit operates "natively" - the commit message and everything is part of the artifact under review exactly like the diff. If the model is to squash an MR into a single commit before merging it, I'd then want to be able to have MRs that depend on each other.
    - seabrookmx 8mo ago
      You can "chain" them and there's some native support for this in Gitlab, but I can't say I've ever tried using it. If I really need a feature branch, I just create a separate branch and target my MR's to that until the whole thing is ready to land in main. Again, it seems less natural to me than how Gerrit does it.

Intralexical 8mo ago

What do people think of ReviewBoard?

maccard 8mo ago

We use perforce in work, and we use p4 swarm. It’s unremarkable, hasn’t changed in a decade and just works. Best part of perforce, by far

jamesfinlayson 8mo ago

I miss Gerrit - it was the first code review tool I used at work. Using GitHub and GitLab as subsequent jobs hasn't been fun.

lima 8mo ago

> But the implementation of Gerrit seems rather unloved There are lots of people who are very fond of Gerrit, and if anything, upstream development has picked up recently. Google has an increasing amount of production code that lives outside of their monorepo, and all of those teams use Gerrit. They have a few internal plugins, but most improvements are released as part of the upstream project. My company has been using it for years, it's a big and sustained productivity win once everyone is past the learning curve. Gerritforge[0] offers commercial support and runs a very stable public instance, GerritHub. I'm not affiliated with them and not a customer, but I talk to them a lot on the Gerrit Discord server and they're awesome. [0]: https://www.gerritforge.com/ https://www.gerritforge.com/