Recent Posts

Gerrit Without the Repo Command

Some people have been told that if you want to use Gerrit code review, then you have to abandon some of your git skills and instead rely on Google's “repo” abstraction. As one of my coworkers recently aptly observed, "git is complicated enough without an additional abstraction layer." However, as you probably presumed from the title of this article, the good news is the rumor is false: even GerritCodeReview.com has “Code Review for Git” as a subtitle; or as I say, "Gerrit was made for git."

Prerequisites

This article presumes that you already have a Gerrit account and a git repository on that Gerrit server.

Get the code with git

Simply use git clone as you always have in the past. In fact, Gerrit is so git-friendly that it will give you the exact git clone command for your project: Projects> List> [project name]> clone, [protocol], where the protocol might be SSH or HTTP. It will probably have a port 29418, as that's typical for Gerrit.. For example:

$ git clone ssh://<username>@review.mydomain.com:29418/ProjectName/

Install a git commit-msg hook

Gerrit can be configured to require a "Change-Id: <hash>" line at the end of the log message for each commit submitted for code review. One could enter these manually; but again, as Gerrit was made for git, every Gerrit server offers a commit-msg hook script that will automatically generate a "Change-Id" line and append it to your log message. This hook installation is a one-time setup for your clone.

$ cd <clone-dirname>
$ scp -P 29419 jdoe@review.mydomain.com:hooks/commit-msg .git/hooks/
$ chmod +x .git/hooks/commit-msg

— For more info: https://gerrit-review.googlesource.com/Documentation/user-changeid.html#creation>

As it is a commit hook instead of a push hook, it can even be safely tested without pushing to Gerrit. Simply make a commit, view the log, and verify that a "Change-Id: I<hash>" line has been appended your commit message.

Push your commit to Gerrit for review (with git, of course!)

I've seen the term "magical" used to describe the "refs/for/<branch_name>" part of this command. Regardless, you don't have to understand it fully, because, suffice to say, "It just works." You can target any remote git branch, but for simplicity, we’ll just use master:

$ git push origin HEAD:refs/for/master
remote:
remote: New Changes:
remote:   https://review.mydomain.com/r/#/c/42/
remote:
⋮
 * [new branch]      HEAD -> refs/for/master

Note:

• The URL in the lines starting with "remote:" is for the page for your change, e.g. in our example, it was assigned change #42.
• The “[new branch]” is a Gerrit “virtual branch”

— For more info: https://gerrit-documentation.googlecode.com/svn/Documentation/2.7/intro-quick.html#_creating_the_review.

So why use the repo command?

To be fair, Google didn’t create repo for nothing. It was motivated by the Android project, which comprises hundreds of individual git repositories. If I were working with that many repositories, I’d script it, too. But here at SDG Systems, where the core of our Android Barcode API builds from a quartet of git repositories, using straight git has been quite reasonable.

Conclusion

Gerrit was made for git. Therefore, “repo” may be helpful in some situations, but it is not required. Git and Gerrit may be used without repo.