[1_800_UNICORN]

Gerrit is the wrong solution for truly agile software development. I had a client ask my team to use it, and it was a real PITA.

The fact that one commit = one merge is ridiculous. It encourages monolithic commits for no reason other than that the tool demands it. It's unrealistic to ask someone to code review multiple commits per feature, and if you tie in your CI it doesn't make any sense to run your build over and over again for a single feature either.

The patchsets DO allow you to see the history of a code review if you have to make changes, but I'd much rather see that live in my git history rather than in Gerrit's history. It's a dirty solution to have to amend your commits to make changes.

Nowhere does the author mention how painful it is if you finish a feature, are waiting for a code review, but have to start the next feature using the code you just wrote. Maybe I'm missing some magical feature in Gerrit that makes this easy, but if you push multiple dependent commits to Gerrit, and one of the early ones gets merged, all of the later ones now have to be rebased because Gerrit created a merge commit in the middle.

[xyzzy_plugh]

> if you push multiple dependent commits to Gerrit, and one of the early ones gets merged, all of the later ones now have to be rebased because Gerrit created a merge commit in the middle.

Someone didn't spend time configuring gerrit or configured it wrong for your use cases. You can solve this in one of two ways: you either fast-forward when possible (gerrit can attempt a trivial rebase) or you commit a change set, create your own merge commit, and then your early ones won't get merged until your last commit. Gerrit will wait to merge the early commits (and vice versa if dependant commits are ready) until everything is good, then merge them all in one shot.

I used gerrit heavily for a few years (and still do, passively, with golang and other public google projects) and I miss it dearly. Sure it's not perfect, but I'd take it over the github fork/make pull requests model any day of the week.

It does not encourage monolithic commits. You need developers to understand what they are doing, care about commit history and be disciplined during development. In my experience, developers who just want to hack shit together, cut corners and love squashing commits or throwing away history hate gerrit. Developers who care love it. It's definitely possible and easy to produce Agile software.

Like anything else, you should use the right tool for the right job. If you're not willing to suck it up and learn something new, then it's not going to have a chance to be the right tool.

[jacobsimeon]

Your argument would be better received sans-ridicule.

I think the OP's point was that Garret hides a lot of features that are built into git and then attempts to paper over that fact by re-implemting those features within its own system.

In your first paragraph, you defend Garrit's rebasing procedure and then you implicitly accuse the OP of not being willing to "suck it up and learn something new".

Why should we learn a new tool that makes (arguably poor) attempts at re-implementing the features of a tool that we already know and love?

[ngrilly]

There's nothing ridiculous in xyzzy_plugh's argument.

The discussed tool is not "Garret" or "Garrit", it's Gerrit, which makes me wonder if you used it before commenting.

As far as I know, Gerrit doesn't reimplement git's features. Rebasing is done using git rebase.

Gerrit is a system for code review, just like GitHub's PR, but with a different approach.

[jacobsimeon]

"Look at this guy mispelled the name of something. He must not know how to identify ridicule"

[nnutter]

It's also possible that they used Gerrit before those features were added which was maybe two years ago.

[oautholaf]

That's funny, as someone who has used both github and gerrit for several years each, I completely disagree. I found the gerrit flow worked well.

At the gerrit-based shop, we kept very good discipline of regular, small checkins. And yes, you can pipeline your checkins too.

I found the gerrit flow also much easier to explain to new engineers. The github PR flow is much more full of sharp edges.

[kiallmacinnes]

> The fact that one commit = one merge is ridiculous. It encourages monolithic commits for no reason other than that the tool demands it.

That's one way of looking at it. Another is, it encourages small self contained units that build to become a full fledged feature.

> It's unrealistic to ask someone to code review multiple commits per feature, and if you tie in your CI it doesn't make any sense to run your build over and over again for a single feature either.

Re CI - Every change to the code should be verified by CI. With gerrit, you can choose to execute the tests for every patchset as its uploaded, or only once it's received a number of reviews or been approved.

> The patchsets DO allow you to see the history of a code review if you have to make changes, but I'd much rather see that live in my git history rather than in Gerrit's history.

I actually kind of agree here, if you migrate away from Gerrit, keeping the review history is hard. Though, every revision of every patchset is actually stored in Git, as are a history of the votes (in the form of a `git note` attached to the commit).

> Nowhere does the author mention how painful it is if you finish a feature, are waiting for a code review, but have to start the next feature using the code you just wrote. Maybe I'm missing some magical feature in Gerrit that makes this easy, but if you push multiple dependent commits to Gerrit, and one of the early ones gets merged, all of the later ones now have to be rebased because Gerrit created a merge commit in the middle.

This really sounds like your Gerrit admins just chose some bad config options..

[MatmaRex]

I use Gerrit everyday (I work on MediaWiki) and I'm not having any problems submitting multiple dependent commits. Yes, you need to rebase the newer ones if an earlier one was non-fast-forward-merged or if an earlier one is amended, but most of the time (if there are no conflicts) this is just a click on the "Rebase" button in Gerrit's interface.

[Washuu]

Gerrit is the reason I rarely submit MediaWiki patches back to the Wikimedia Foundation. Gerrit is a giant pain to use, has a terribly designed interface, and requires a command line plugin that makes it trivial to screw up patch reviews. I can not ask other developers on the team here to do it either since I can not justify having them hours just to learn how to not screw up using Gerrit.

[MatmaRex]

The git-review plugin is not required, you can instead do `git push gerrit HEAD:refs/for/master` to push changes for review and use the snippets from the change's page to pull them. But it's easier to do `git review` and `git review -d` instead, and it doesn't require understanding or memorizing the weird push command. (I work on MediaWiki, by the way.)

[djsumdog]

I used Gerrit for over a year at one company and I have to agree. Every minor change required amending a commit and another review. It really breaks a lot of the git process.

I also had to admin a Gerrit server once and the documentation (at the time at least) for setting up and running a Gerrit server was total shit. It was a painful process to say the least.

Another project, which took many of my old team members, started using Gitlab instead and they loved it. The merge requests made a lot more sense. I'm currently at a new company that uses Gitlab and I have to agree.

Both systems are pretty much suggestive. We could always +1 a code review ourselves if it had to get out that day, but it's best someone else did it and there was a record. Gitlab is a lot more lose. There's no official field for an approval, but you can put in a nice little thumbs up emoji in your comment, and you have the same audit trail.

TL;DR +1 Gitlab (et al.) over Gerrit for sure

[sytse]

Glad to hear you like GitLab! And if you want something more formal GitLab EE has merge request approva; https://about.gitlab.com/2015/06/16/feature-highlight-approv...