Hacker News Reader

Comment by csl | Hacker News Reader

Is Gerrit really that terrible? I do agree that clicking through each file is a waste, but I love the ability to work on several different reviews and keep track of their different build statuses.

Also, where I use it we have different levels of requirements for different branches (more people usually need to approve reviews on soon-to-be-released point branches). We use it for a large project in MLOCs but relatively few developers (less than a hundred). I can't see it would work for 4000 devs at all, though.

View on HN

In my opinion, yes, Gerrit is awful.

Perhaps my experience is made worse by the fact that our Gerrit servers (perhaps about 5000 users) are so painfully slow that it can take a minute to display a page. Multiply that by the number of files touched in a patch to get a whole review done.

Then add all this non-vanilla Git extensions like "Change-Id" lines in commit messages and Gerrit/Repo's awkward idea of branches spanning multiple repositories.

All this makes it difficult to deal with multiple patches that make a "feature", ie. a feature branch. Something that should be trivial in Git is made really difficult by Gerrit.

Our team of 10 thinks Gerrit is great. I don't know how these other people are using Gerrit, but I don't recognize their description at all. Gerrit is very convenient if you take code reviews seriously.

  I do agree that clicking through each file is a waste

Well, firstly it is simply not true that you need to do that (you can accept/reject a review without having viewed any file at all), but secondly I'm totally fine with pressing ] 20 times for a review that touches 20 files. If the diff was a single unified diff, I'd have to press page-down a few times and those few keystrokes don't make much of a difference compared to the time taken to actually review code.

Article says:

  Gerrit, he said, makes patch submission quite hard

But without any explanation for why.

  It is hard to do local testing of patches in Gerrit,

It's easy to checkout a review to its own branch, so why do they feel that way?

  All discussions are done through a web interface.

Yeah, well, if using a web interface is a problem for you, then of course Gerrit is not a good tool for you. If you think the web interface doesn't add anything, then Gerrit is not a good tool for you. But those are not shortcomings of Gerrit, but simply a mismatch between your preferred workflow and your preferred way of interacting with code reviews.

> Article says: > Gerrit, he said, makes patch submission quite hard > But without any explanation for why.

You need to add hooks to inject a Change-Id into every commit, and be careful that they're still "fresh" (e.g. you cannot reuse one from an abandoned branch if you want to re-submit it).

And you must push a diff to the server so it can be submitted to Gerrit. If your feature branch is up-to-date (you just force-pushed it), you cannot submit the same commit to Gerrit.

And it gets worse when you have developers who rely on an IDE to get work done – the IntelliJ plugin for Gerrit is pretty buggy (I think it's okay for submitting now, but reviewing was still frustrating last month).

  If your feature branch is up-to-date (you just force-
  pushed it), you cannot submit the same commit to Gerrit.

It sounds to me like this is where it's going wrong. If Gerrit is not also hosting your 'origin' git repositories and acting as a gatekeeper for any commit to be added to it, then you are working against the system.

I don't see the problem with hooks and we rarely have problems with Change-Ids not being 'fresh' anymore (that sounds like the result of a suboptimal workflow).

Bugs in plugins are of course not a good reason to say Gerrit isn't very good. That's like saying git itself sucked when the IntelliJ plugin for git still had annoying bugs.

> If Gerrit is not also hosting your 'origin' git repositories and acting as a gatekeeper for any commit to be added to it, then you are working against the system.

It is/was. But if I push my work to origin/features/foo, then push the same commit to refs/for/master, it will not create a review because no new commit has been introduced. At least that's my experience and it is (kind of) spelled out like that in the manual [1]: "Each new commit uploaded by the git push client will be converted into a change record on the server."

I've only tried this a couple of times, so hopefully that was a case of PEBKAC.

> Bugs in plugins are of course not a good reason to say Gerrit isn't very good.

Services like GitLab/GitHub/Bitbucket work with every git GUI out of the box, because all you need to do is to push branches and then open a web browser. With Gerrit, you need to know how to push to a magic URL (especially if you want to specify a topic or message), or you'll need a plugin. I don't blame Gerrit for the low quality of the IntelliJ plugin, but for needing a plugin in the first place.

[1] https://gerrit-review.googlesource.com/Documentation/user-up...

Perhaps I don't understand the Gerrit workflow, but last time I read about Gerrit it looked like it had a philosophy of "one commit, one review".

That sounds like an anethema for the kernel, where they want to review a series of tidied up commits, one per email.

Gerrit does have "one commit, one review", but - that's not a bad thing. If a change is well written and structured, merging the first in the chain without the second+ is both harmless and is progress towards the end goal.

There's also patch chains in Gerrit, so you can see the X commits that make up the full change, and the second+ cannot be merged before the first.

Does the topic branch feature help? I personally always use it.

Could you elaborate why you think gerrit wouldn't work for 4000 devs?

At that scale the project would be divided into smaller responsibility areas essentially operating on their own anyway.

Right, you could do that and probably do it well.

I was mostly thinking about the simple matter of scaling the resources and maintenance crew to tackle 4000 devs. But my biggest concern about it is that it introduces centralization into the workflow. I do truly love Gerrit, but I get a bit worried about keeping a lot of important stuff in a centralized and not so transparent database.

Reply on news.ycombinator.com