38 ms·

I am yet to know people who Review code and use Gerrit to name a better solution. I belonged to a team that used Gerrit for Review and Hosting, we changed to h

I am yet to know people who Review code and use Gerrit to name a better solution. I belonged to a team that used Gerrit for Review and Hosting, we changed to hosted Gitlab because people missed a "GitHub-like UI" they were used to. It was unanimous that Code Review on Gerrit was way better: 1. You start reviewing the commit message, that is the first touch point with a change everyone has 2. Navigation is done from file to file 3. On Gerrit there isn't two people commenting the same thing, because: 3.a. Messages from different people on the same line change are displayed together, not as different threads. 3.b. The review of a previous version is displayed with the next version, so you can continue the same discussion I understand that GitHub/GitLab interface is more friendly, but their code-review really stands in the way of producing good software by not favoring good commit messages and long discussions.

u801e 6y ago
> I am yet to know people who Review code and use Gerrit to name a better solution. What about reviews via patches sent to a mailing list? I haven't looked into Gerrit for a while, so one question I have is how it handles related commits? The mailing list approach can group them in a single thread tied by a cover letter message where each commit along with the associated diff from the parent working tree is a message which is a reply to the cover letter message.
- AaronFriel 6y ago
  To be polite, I think the target audience of these tools might not include you. While that workflow works for you and, apparently, scales for some very large projects like the Linux kernel, it isn't a good solution for an enormous number of people which is why tools like Github, Gerrit, GitLab, and others exist.
  - u801e 6y ago
    > To be polite, I think the target audience of tools might not include you. Insinuating that I'm a special case doesn't add to the discussion.
    - AaronFriel 6y ago
      You aren't a special case, but if you don't see any flaws with your method of code review then I don't think you're the target market for code review tools.
      - u801e 6y ago
        Now you're claiming that I'm making an argument that I never made. To be clear, the original statement was whether there was a better review tool compared to Gerrit for those who review code and use that tool for that purpose. I responded by suggesting the patch review via mailing list method and asked a follow up question about how Gerrit handled related commits and explained how that case was handled by the mailing list method. Then you, not the person I originally responded to, decided to interject and, while claiming not to be rude, claims I'm saying something entirely different than what I actually stated. Personally, I found that very off putting and extremely rude on your part.
        waheoo 6y ago
        Gerrit handles related commits in a similar way I guess. A Gerrit changeset is like a GitHub pr, it has many commits, and commits are usually rebased against master, this is crucial to track the review properly over time. (Its very easy to switch to earlier revisions of the same changeset and you never see external changes.) Honestly, I don't think Gerrit is anything special, I think it simply has the right approach to development (rebased/ff-only) that enables easy review.
        u801e 6y ago
        Based on the documentation I read, it looks like Gerrit handles this by grouping changes by topics [1]. I'm not sure whether that can be done automatically when pushing up changes that span multiple commits in a local branch. If I create a branch with several commits where one commit adds a new method with associated unit tests, and a subsequent commit adds several calls to that new method in the code base (while updating any affected tests), then how would Gerrit handle the ordering of those commits. Even if they're in the same topic, I don't know if there's a way to ensure that the first commit is reachable from the subsequent commit. [1] https://gerrit-review.googlesource.com/Documentation/intro-user.html#topics https://gerrit-review.googlesource.com/Documentation/intro-u...
pedroms 6y ago
I'm a Product Designer at GitLab and I appreciate your feedback. We are well aware of the advantages that Gerrit has over GitLab and how these are emphasized when teams migrate to GitLab. We are working on improvements that will help mitigate this. Specifically, targeting your points: 1. We're discussing ability to comment on commit messages: https://gitlab.com/gitlab-org/gitlab/-/issues/19691 https://gitlab.com/gitlab-org/gitlab/-/issues/19691 2. From version 13.2 you can opt to show one file at a time, in your user preferences: https://gitlab.com/gitlab-org/gitlab/-/issues/222790 https://gitlab.com/gitlab-org/gitlab/-/issues/222790. We have also listed a number of improvements to this feature in https://gitlab.com/groups/gitlab-org/-/epics/516 https://gitlab.com/groups/gitlab-org/-/epics/516. Could you expand on point 3.b? If the commented line hasn't changed from version A to B, you should be seeing the comment in version B. Or maybe you're referring to something else?

u801e 6y ago

> I am yet to know people who Review code and use Gerrit to name a better solution. What about reviews via patches sent to a mailing list? I haven't looked into Gerrit for a while, so one question I have is how it handles related commits? The mailing list approach can group them in a single thread tied by a cover letter message where each commit along with the associated diff from the parent working tree is a message which is a reply to the cover letter message.

AaronFriel 6y ago
To be polite, I think the target audience of these tools might not include you. While that workflow works for you and, apparently, scales for some very large projects like the Linux kernel, it isn't a good solution for an enormous number of people which is why tools like Github, Gerrit, GitLab, and others exist.
- u801e 6y ago
  > To be polite, I think the target audience of tools might not include you. Insinuating that I'm a special case doesn't add to the discussion.
  - AaronFriel 6y ago
    You aren't a special case, but if you don't see any flaws with your method of code review then I don't think you're the target market for code review tools.
    - u801e 6y ago
      Now you're claiming that I'm making an argument that I never made. To be clear, the original statement was whether there was a better review tool compared to Gerrit for those who review code and use that tool for that purpose. I responded by suggesting the patch review via mailing list method and asked a follow up question about how Gerrit handled related commits and explained how that case was handled by the mailing list method. Then you, not the person I originally responded to, decided to interject and, while claiming not to be rude, claims I'm saying something entirely different than what I actually stated. Personally, I found that very off putting and extremely rude on your part.
      - waheoo 6y ago
        Gerrit handles related commits in a similar way I guess. A Gerrit changeset is like a GitHub pr, it has many commits, and commits are usually rebased against master, this is crucial to track the review properly over time. (Its very easy to switch to earlier revisions of the same changeset and you never see external changes.) Honestly, I don't think Gerrit is anything special, I think it simply has the right approach to development (rebased/ff-only) that enables easy review.
        u801e 6y ago
        Based on the documentation I read, it looks like Gerrit handles this by grouping changes by topics [1]. I'm not sure whether that can be done automatically when pushing up changes that span multiple commits in a local branch. If I create a branch with several commits where one commit adds a new method with associated unit tests, and a subsequent commit adds several calls to that new method in the code base (while updating any affected tests), then how would Gerrit handle the ordering of those commits. Even if they're in the same topic, I don't know if there's a way to ensure that the first commit is reachable from the subsequent commit. [1] https://gerrit-review.googlesource.com/Documentation/intro-user.html#topics https://gerrit-review.googlesource.com/Documentation/intro-u...

pedroms 6y ago

I'm a Product Designer at GitLab and I appreciate your feedback. We are well aware of the advantages that Gerrit has over GitLab and how these are emphasized when teams migrate to GitLab. We are working on improvements that will help mitigate this. Specifically, targeting your points: 1. We're discussing ability to comment on commit messages: https://gitlab.com/gitlab-org/gitlab/-/issues/19691 https://gitlab.com/gitlab-org/gitlab/-/issues/19691 2. From version 13.2 you can opt to show one file at a time, in your user preferences: https://gitlab.com/gitlab-org/gitlab/-/issues/222790 https://gitlab.com/gitlab-org/gitlab/-/issues/222790. We have also listed a number of improvements to this feature in https://gitlab.com/groups/gitlab-org/-/epics/516 https://gitlab.com/groups/gitlab-org/-/epics/516. Could you expand on point 3.b? If the commented line hasn't changed from version A to B, you should be seeing the comment in version B. Or maybe you're referring to something else?