Gerrit is wrong. Gerrit is evil!
Gerrit is wrong. Gerrit is evil. Gerrit is the beginning of all hell! If you’re considering using it as version control system, you’re most likely out of your mind! And you’re asking yourself for a big troubles. If you’re forced to use it (like I was), then believe me… your worst nightmares are ahead of you. Nothing, you seen in code review or version control systems up until now, hasn’t prepared you for the pain you’re about to suffer…
I like synosises, so let’s deal with this in points! Shall we…
1. One of the biggest Gerrit’s stupidities — dependencies. Each new change (commit) in the same branch depends on previous one, though it most likely covers completely different area or aspect of your code. Especially painfull, if you’re not using branches and commiting directly to master (happens often in one developer sites or in a very small teams). If you abandon a change, any following it will not be auto-merged and you’ll not be able to merge it manually, until you don’t do some strange magic with your local repo. Yes, that is. Your entire project will be stopped, because you abandoned one change. Sounds insane? Welcome to Gerrit’s world! Here you have more details. The only workaround for this, that I know, is to always use local branches. They’re often called topic branches. Because they’re short-living (most time created only to fix some issue) and in most cases they’re not shared (only one developer is working on particular branch, and it is merged into master immediately after pushing to Gerrit and reviewing it there). Only local branches can save you from dependencies-horror. Note, that you don’t create corresponding remote branches on Gerrit side!
2. If you’re pusing your changes to Gerrit, you have to execute git push with proper refs. Most times it is git push origin HEAD:refs/for/master, as you don’t usually create remote branches to Gerrit or push your local to it. If you forget about this refs, you’re deeply in big black ass. Gerrit will add your branch to the branches list for your project (or do nothing, if you’re pushing to master), but you’ll not find your change anywhere. And there’s no much you can do (here are some ideas). To make things even worse, if you commit another change to the very same branch, and push it to Gerrit, this time with correct refs, Gerrit will auto-merge that branch into master… with only new changes, you’ve just commited & pushed! I simply can’t understand stupidity, when some program or service allows a user to perform nearly unrecoverable, that it can’t deal with. It looks like that: I’m pushing with an error, Gerrit have no bloody idea, what to do with that push (adds branch, but not the change), but allows me to continue.
3. As I wrote above, using remote branches (on Gerrit side) is in most cases not advised. But, if you decide to do it, you may find out that, when pushing a particular branch, with all mandatory refs correctly set (i.e. git push origin HEAD:refs/for/{branch}, it will also be rejected, until… you won’t go to UI and create this branch manually there. Up until version 2.9 such obvious, basic, fundamental feature like being able to create branch via SSH (automatically with each push) wasn’t implemented at all. And, if you look at initial feature request date you’ll again find out, that it took over two years to implement such obvious things and it finally had to be implemented by some other guy, not by someone from core dev team. LOL!
4. There is a general-behaviour, huge bug in Gerrit (not being able to push changes in master after merging some branch to it), that was reported to Gerrit’s bug tracking system in the beginning of October, 2011. Again, still hasn’t been fixed! For over two years a general bug exists and Gerrit users must use a work-around! Fantastic…
My two-weeks struggle with Gerrit resulted with many questions asked on Stack Overflow. As of writing this text, none of them were closed as off-topic, most were answered and some were up-voted. Meaning, that these wasn’t too stupid questions and other has similar problems or doubts with Gerrit. I agree, that some of them resulted as my lack of knowledge of sweet details of Gerrit (ten points for people responssible for Gerrit’s documentation), but even so, consider looking at them, if everything else fails. You may find some light or hope there.
Though, I finally get thing to (somehow) working, I did not changed my opinion. Gerrit is wrong and evil. Gerrit is the beginning of all hell! It is the last code review system, I would advice to anyone. The only salvation is to STOP USING GERRIT !!!. Or never even trying to use it. If you’re forced to used by some higher authority, be sure, that your nice days are over. Now, it will only be pain and suffer.