Abandoning Bitbucket server in favor of Gerrit

At Cosium, code review is at the core of our product creation. We consider it the first line of defense against software defects and technical debt.

From Crucible to Bitbucket server

2 years ago, we were using Crucible. Crucible is a post commit code review tool. At that time, our increasing involvement in open source made us familiar with GitHub and GitLab pull request (PR) workflow. Based on those experiences, we decided to replace Crucible with a pull request review tool.

After comparing GitHub enterprise, GitLab and Bitbucket server, we selected Bitbucket server as our new code review tool.

Bitbucket server: the bad parts

During the last 2 years, Bitbucket server has served us well, but we also have had plenty of time to notice some critical downsides.

Unified diff appears in black and white. No syntax highlighting at all. This ticket has been opened for 6 years now ! 
You might say that we just have to switch to the side-by-side diff to make it work. But since Bitbucket has two levels of fixed left menus, the side-by-side diff overflows horizontally …

need work status is unusable. This status is removed every time a commit is made. You should be able to push a commit to a branch without triggering the pull request re-opening. This leaves us with decline.

And now, the worst part. When a PR exceeds 20 comments, it becomes unreadable. Comments attached to “old code” are only visible from the overview tab, there is no way to see them again in the diff tab. 
As a reviewer, in order to view the action that the authors took following your “old comments”, you have to open Bitbucket in 2 browser tabs, one on the overview tab and the other on the diff tab. Then you have to follow the Twitter like linear overview tab timeline on one side while trying to rematch the latest diffs in the diff tab. It is totally unpractical. Bitbucket is not the only one to blame as GitLab and Github didn’t come up with a better system.

The eye opener

Despite those bad parts, we considered that Bitbucket was still better than its competitors. But was it?

Many Google open source projects use Gerrit as code review tool. Recently, we had the opportunity to make a thorough use of Gerrit for our first Chromium project contribution.

Our first change set (Gerrit term for PR) in Chromium involved a code patch of 800 added lines that led to a discussion of hundred of comments and 42 code revisions. Everything was managed by Gerrit. And despite those numbers, everything was crystal clear !

You can easily compare two patch sets (Gerrit term for revisions). Each comment is engraved in its patch set. When you look at the diff between two patch sets, you can have on the left the old revision code with the old attached comments and on the right the new revision code with answers from the author.

Comparing patch set 34 with patch set 35

You can reply to, quote, acknowledge and mark each comment done.

Side-by-side diff is the default. Since it takes the whole screen width, the code doesn’t overflow horizontally. Syntax highlighting just works.

Reviewers can sum-up their opinions about the change set through a system of votes.

The migration process

To ease the migration from Bitbucket to Gerrit, we created an open source tool.
bitbucket-to-gerrit is a node CLI that automates the migration of git repositories from Bitbucket to Gerrit.

Conclusion

Given this journey, we think that we found in Gerrit, our Holy Grail of code review tools.