First of all, we had to prepare our desktop, using those instructions, which I did, one day ahead of the conference, using the official Egit repo (Egit 0.11.3) and eclipse 3.6.2.

Four presenters were present : Stefan Lay, Shawn Pearce, Matthias Sohn and Chris Aniszczyk.

Presentation

They began with a very quick  presentation of Git, that they defined as a tool to facilitate code review, and then Git at Eclipse

• a roadmap has been defined to move to git
• CVS is being deprecated

They defined what is a modern code review and its benefits

• when a developer writes code, another checks it
• 4 eyes catch more bugs
• mentoring of new developers
• establish trust relationships
• good alternative to pair programming
• coding standards

Git sits between the developer desktop and the CI machine : as a tool to review code and accept changes

Tutorial

For the tutorial, I chose the HTTP protocol rather than SSH, to make sure I would not suffer from any eventual proxies.

When cloning the sample git repository, I noticed that you can specify another destination folder than your current workspace directory, Stefan mentioned it is to allow you to have your git repo not deleted when you delete your workspace… (anyway, you can also clone to your workspace, just as with Subversion)

• First connection test

right click : team->remote->configure push to upstream…, and then add refs/for/master in the ref spec (or else it will try to push to the master repo); the magic Ref refs/for/master represents the Gerrit code review queue for the master branch on the server.

Then click save and push, it will fail because there were no changes; but you just had the opportunity to check your settings are ok.

Exercises :

All the exercises are described here.

During those exercises, we created a local change, then submit it for a review in gerrit.

Just after sending my changes, Hudson was triggered to launch a build against my local branch that I just committed.

Then, the build passed (alright !) and it was really fun since people in the room would review my changes with comments; finally someone approved my changes and my changes were merged into the master branch.

Other exercises implied more advanced workflow such a submitting other change sets and registering projects to monitor, but I did not have time to do them all; actually I strongly advise anyone wanting to try gerrit out to complete those exercises. (you will have to do them with a friend, since someone will have to accept your changes

Actually, I was really impressed with this tool : it really changed the perception I had of code review (with patches sent via email + code review on the desktop of the co worker); just letting the developer do all the changes he want, then see Hudson builds his changes, ask a reviewer (or a reviewer adds himself to the bug), see the file to file comparison, the comments in the gerrit web interface… I’m totally convinced !!! Social coding for real !

I had a chat during this session with Shawn Pearce, from Google, the actual author and main contributor of Gerrit; he explained to me how people and organizations (including Google developers) were hooking Gerrit with Mylin, IRC, Hudson; for now using SSH and the web UI, but he told me a web service interface (based on REST) was on his mind; to ease integration with external tools; as for the authentication, he told me that Gerrit could be linked with Bugzilla and being part of a SSO scheme , using your enterprise LDAP for example

I did not expect so much from this git and gerrit tooling, you got to see it to believe its awesomeness !!!