7 ms·

This is sad. In my experience, Gerrit is a much better code review system than Gitlab merge requests. But it is different from what people are used to.

by q3k 6y ago

epistasis 6y ago
What advantages do you see in Gerrit? Do they require a lot of experience in order to be realized?
- q3k 6y ago
  Clear mapping of change request == commit, allowing for easy building of multiple in flight change requests, rearranging them by using git rebase, updating with push to refs/for/master. Easy diffing between states of the CR (patch sets), so you can see what changes since the last round of comments, even if it spanned multiple updates. This is the feature I miss the most from other code review systems - be able to easily work on another commit that bases on one that I just sent out for review (even starting review on the new while the parent still hasn't finished being reviewed!), and rebasing my current change as the parent change gets reviewed/updated. Possibility to send out a PR for review using just a push (change message in commit, push to refs/for/master%r=foo). Snappy and compact code review experience (no space wasted for whitespace, avatars, pretty buttons). Full coverage with keyboard shortcuts. Powerful review rule system based in Prolog, allowing for things like code owners, experimental subdirectories without the need for review, etc.
  - dionian 6y ago
    > Clear mapping of change request == commit, was forced to use Gerrit by a client. I could never get the hang of this, I like to do frequent commits on short lived branches and using vanilla git. I never wanted any more features other than a nice UI to encourage people to review.
    - q3k 6y ago
      The nice UI for review works well exactly because it limits the functionality available to users and enforces a particular commit model. If you don't do that, you get the code review mess that are Github/GitLab PRs/MRs - difficult to tell apart how commits relate to the change and how it progresses through review, because the entire branch history is free-form.
      - kevincox 6y ago
        It's possible to allow users to have multiple commits but still show review between the submitted "tip" commits. If you want you don't even need to show the other commits in the UI.
    - detaro 6y ago
      One thing one has to get away from that one change request == one issue. Multiple small commits as separate change requests for one story are fine as long as they work standalone (which is generally a good idea, e.g. to enable bisecting)
- js2 6y ago
  I much prefer the model of force-pushing your development branch to create change sets. It lets you more easily see how development evolves in response to feedback. And the final state of the branch which gets merged leaves all the in-progress work that no one cares about behind only in Gerrit. With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. Alternately, if you just keep adding commits, then the final branch that gets merged (unless you squash) has all the in-progress work which pollutes the repo's history. Gerrit also has a finer grained permission model, but I don't care as much about that. Gerrit definitely expects the user to understand how git works conceptually a bit more than Github/lab.
  - nemetroid 6y ago
    > With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. That's not quite true. Gitlab lets you compare any two "versions" of the force pushed branch.
    - js2 6y ago
      Thanks. I haven’t used gitlab. I assumed it worked the same as GitHub. That’s good to know.
      - kevincox 6y ago
        Yup, GitLab works as expected here. It's always surprised me how quickly the old commit is garbage-collrcted when you force-push a branch on GitHub. It causes weird errors in CI runs and breaks viewing the old commits. Seriously I'll pay for those couple of KiB of space, just keep it around. (at least until the PR is closed)
  - 0x0 6y ago
    Gitlab DOES let you compare different versions of changesets in a merge request: https://docs.gitlab.com/ee/user/project/merge_requests/versions.html https://docs.gitlab.com/ee/user/project/merge_requests/versi...
  - 6y ago
PieUser 6y ago
This is sad. In my experience, GitHub is a much better code review system than GitLab merge requests. But it is different from what people are used to.
dietrichepp 6y ago
Probably because you got used to Critique at Google ;) I agree though. I think the most important thing in a code review system is inline comments in the diff itself, and that’s something you get from Gerrit, Phabricator (Differential), etc. It encourages people to discuss the particulars of of a diff. Merge approval can be made contingent on resolving minor issues within a diff. Diffs are also approved on a per-diff basis, and it’s less typical to merge a stack of diffs. I think the pull request / merge request makes sense with the “trusted lieutenants” development model that the Linux kernel uses, but for other projects you would be more likely to want a work flow where someone submits a single commit/diff and then someone approves it (after comments). When I review PRs on services like GitHub I very often think, “This should be several different reviews” and the discussion thread in a PR is often not a high-quality discussion. I don’t use GitLab as much but my experience is that it has the same problems. What I would love is to review a stack of commits and approve / make comments on the commits individually. (For those reading: Mondrian -> Rietveld -> Gettit, and also Mondrian -> Critique. Mondrian and Critique are internal tools at Google. Phabricator originated at Facebook which has a lot of ex-Google engineers on staff.)
- nemetroid 6y ago
  I don't use Github much, but Gitlab allows for multiple threads in a merge request. These threads may reference diffs/commits, but can also be directed at the merge request in general. Each thread has to be explicitly resolved before merging.
- eatthoselemons 6y ago
  Do you think that gitlab will ever add inline diff comments? I don't know if it would even be feasible to add to gitlab
  - e12e 6y ago
    More online than comments on the changes in the Mr? Like: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/26540/diffs https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/2... (there's some old discussion on there, random example)
huskyr 6y ago
I guess you can get the hang of Gerrit, but i tried it out a couple of times (i occasionally do work on projects in the Wikimedia git repo) and is pretty evident that the interface is written by developers with little knowledge of user experience. Moving stuff to Gitlab will probably increase the number of volunteer contributions, at least i'm more interested in contributing more now.
- q3k 6y ago
  I really don't mind the Gerrit UX - it seems to be optimized for daily use by programmers, not for onboarding speed. That's a tradeoff I'm very much okay with.
  - badrequest 6y ago
    You're okay with the tool being difficult to use because you already know how to use it.
    - q3k 6y ago
      I'm okay with it being slightly more difficult to get started with, in return for higher productivity in the long run, yes. Right now, after spending a similar amount of time both with GitHub PRs (and Gitlab MRs) and Gerrit, I still find Gerrit much easier and faster to use.
      - llimllib 6y ago
        I'm generally okay with that tradeoff too, but we tried it early on at our company and the juice was not worth the squeeze, at least in our case. Designers and even many developers found it essentially impossible to use and the developers who were reasonably comfortable with it spent way too much time assisting others in attempting to use it. (fwiw I found myself somewhere in the middle - I like the model and understood the ideas but also found it annoying to work with in practice)
        6y ago
finnthehuman 6y ago
It's depressing how git tooling has to squish out all the flexibility that makes git attractive in the name of being unsurprising to someone who doesn't understand git. I was excited to finally bring in git as we start ramping down on a legacy project onto something new. Then I started thinking about the developers that have never touched git and I need to support. I looked at the tools available and what workflows they dictate. Then there's the drive to do something similar to the rest of the company, autonomy only goes so far without a good reason. Fuck me. I'm going to pick GitLab and hate it.
Entaroadun87 6y ago
Why is it sad? They've identified a better experience for their target audience, new community devs, just that not perhaps for you haha.
okhan 6y ago
I had to use Gerrit in a previous job, and _hated_ it. The UX is abysmal. Some folks loved it though, especially engineers working mostly on the backend. People with more of a frontend focus couldn't get past the awful user experience.
- alessioalex 6y ago
  Can confirm, it's extremely off-putting to say the least. Having previously used Github, Gitlab, Bitbucket I find Gerrit very unusual. I have to Google on how to do basic stuff.

This is sad. In my experience, Gerrit is a much better code review system than Gitlab merge requests. But it is different from what people are used to.

by q3k 6y ago

This is sad. In my experience, Gerrit is a much better code review system than Gitlab merge requests. But it is different from what people are used to.

epistasis 6y ago

What advantages do you see in Gerrit? Do they require a lot of experience in order to be realized?

q3k 6y ago
Clear mapping of change request == commit, allowing for easy building of multiple in flight change requests, rearranging them by using git rebase, updating with push to refs/for/master. Easy diffing between states of the CR (patch sets), so you can see what changes since the last round of comments, even if it spanned multiple updates. This is the feature I miss the most from other code review systems - be able to easily work on another commit that bases on one that I just sent out for review (even starting review on the new while the parent still hasn't finished being reviewed!), and rebasing my current change as the parent change gets reviewed/updated. Possibility to send out a PR for review using just a push (change message in commit, push to refs/for/master%r=foo). Snappy and compact code review experience (no space wasted for whitespace, avatars, pretty buttons). Full coverage with keyboard shortcuts. Powerful review rule system based in Prolog, allowing for things like code owners, experimental subdirectories without the need for review, etc.
- dionian 6y ago
  > Clear mapping of change request == commit, was forced to use Gerrit by a client. I could never get the hang of this, I like to do frequent commits on short lived branches and using vanilla git. I never wanted any more features other than a nice UI to encourage people to review.
  - q3k 6y ago
    The nice UI for review works well exactly because it limits the functionality available to users and enforces a particular commit model. If you don't do that, you get the code review mess that are Github/GitLab PRs/MRs - difficult to tell apart how commits relate to the change and how it progresses through review, because the entire branch history is free-form.
    - kevincox 6y ago
      It's possible to allow users to have multiple commits but still show review between the submitted "tip" commits. If you want you don't even need to show the other commits in the UI.
  - detaro 6y ago
    One thing one has to get away from that one change request == one issue. Multiple small commits as separate change requests for one story are fine as long as they work standalone (which is generally a good idea, e.g. to enable bisecting)
js2 6y ago
I much prefer the model of force-pushing your development branch to create change sets. It lets you more easily see how development evolves in response to feedback. And the final state of the branch which gets merged leaves all the in-progress work that no one cares about behind only in Gerrit. With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. Alternately, if you just keep adding commits, then the final branch that gets merged (unless you squash) has all the in-progress work which pollutes the repo's history. Gerrit also has a finer grained permission model, but I don't care as much about that. Gerrit definitely expects the user to understand how git works conceptually a bit more than Github/lab.
- nemetroid 6y ago
  > With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. That's not quite true. Gitlab lets you compare any two "versions" of the force pushed branch.
  - js2 6y ago
    Thanks. I haven’t used gitlab. I assumed it worked the same as GitHub. That’s good to know.
    - kevincox 6y ago
      Yup, GitLab works as expected here. It's always surprised me how quickly the old commit is garbage-collrcted when you force-push a branch on GitHub. It causes weird errors in CI runs and breaks viewing the old commits. Seriously I'll pay for those couple of KiB of space, just keep it around. (at least until the PR is closed)
- 0x0 6y ago
  Gitlab DOES let you compare different versions of changesets in a merge request: https://docs.gitlab.com/ee/user/project/merge_requests/versions.html https://docs.gitlab.com/ee/user/project/merge_requests/versi...
- 6y ago

PieUser 6y ago

This is sad. In my experience, GitHub is a much better code review system than GitLab merge requests. But it is different from what people are used to.

dietrichepp 6y ago

Probably because you got used to Critique at Google ;) I agree though. I think the most important thing in a code review system is inline comments in the diff itself, and that’s something you get from Gerrit, Phabricator (Differential), etc. It encourages people to discuss the particulars of of a diff. Merge approval can be made contingent on resolving minor issues within a diff. Diffs are also approved on a per-diff basis, and it’s less typical to merge a stack of diffs. I think the pull request / merge request makes sense with the “trusted lieutenants” development model that the Linux kernel uses, but for other projects you would be more likely to want a work flow where someone submits a single commit/diff and then someone approves it (after comments). When I review PRs on services like GitHub I very often think, “This should be several different reviews” and the discussion thread in a PR is often not a high-quality discussion. I don’t use GitLab as much but my experience is that it has the same problems. What I would love is to review a stack of commits and approve / make comments on the commits individually. (For those reading: Mondrian -> Rietveld -> Gettit, and also Mondrian -> Critique. Mondrian and Critique are internal tools at Google. Phabricator originated at Facebook which has a lot of ex-Google engineers on staff.)

nemetroid 6y ago
I don't use Github much, but Gitlab allows for multiple threads in a merge request. These threads may reference diffs/commits, but can also be directed at the merge request in general. Each thread has to be explicitly resolved before merging.
eatthoselemons 6y ago
Do you think that gitlab will ever add inline diff comments? I don't know if it would even be feasible to add to gitlab
- e12e 6y ago
  More online than comments on the changes in the Mr? Like: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/26540/diffs https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/2... (there's some old discussion on there, random example)

huskyr 6y ago

I guess you can get the hang of Gerrit, but i tried it out a couple of times (i occasionally do work on projects in the Wikimedia git repo) and is pretty evident that the interface is written by developers with little knowledge of user experience. Moving stuff to Gitlab will probably increase the number of volunteer contributions, at least i'm more interested in contributing more now.

q3k 6y ago
I really don't mind the Gerrit UX - it seems to be optimized for daily use by programmers, not for onboarding speed. That's a tradeoff I'm very much okay with.
- badrequest 6y ago
  You're okay with the tool being difficult to use because you already know how to use it.
  - q3k 6y ago
    I'm okay with it being slightly more difficult to get started with, in return for higher productivity in the long run, yes. Right now, after spending a similar amount of time both with GitHub PRs (and Gitlab MRs) and Gerrit, I still find Gerrit much easier and faster to use.
    - llimllib 6y ago
      I'm generally okay with that tradeoff too, but we tried it early on at our company and the juice was not worth the squeeze, at least in our case. Designers and even many developers found it essentially impossible to use and the developers who were reasonably comfortable with it spent way too much time assisting others in attempting to use it. (fwiw I found myself somewhere in the middle - I like the model and understood the ideas but also found it annoying to work with in practice)
      - 6y ago

finnthehuman 6y ago

It's depressing how git tooling has to squish out all the flexibility that makes git attractive in the name of being unsurprising to someone who doesn't understand git. I was excited to finally bring in git as we start ramping down on a legacy project onto something new. Then I started thinking about the developers that have never touched git and I need to support. I looked at the tools available and what workflows they dictate. Then there's the drive to do something similar to the rest of the company, autonomy only goes so far without a good reason. Fuck me. I'm going to pick GitLab and hate it.

Entaroadun87 6y ago

Why is it sad? They've identified a better experience for their target audience, new community devs, just that not perhaps for you haha.

okhan 6y ago

I had to use Gerrit in a previous job, and _hated_ it. The UX is abysmal. Some folks loved it though, especially engineers working mostly on the backend. People with more of a frontend focus couldn't get past the awful user experience.

alessioalex 6y ago
Can confirm, it's extremely off-putting to say the least. Having previously used Github, Gitlab, Bitbucket I find Gerrit very unusual. I have to Google on how to do basic stuff.