Estimated read time: 2 minutes
LibreOffice started to use Gerrit for code review, and while occasional contributors can submit patches manually, in case one does many reviews, it’s handy to use a dedicated tool. In core.git, we have logerrit, but that’s not advised for regular reviewers, either, git-review is recommended instead.
So I looked into git-review. The good news is that it’s packaged already for most distributions, e.g. a simple
zypper in python-git-review
on openSUSE installs it.
I wanted to use this tool for two tasks:
-
Submitting changes to Gerrit:
git review -R
could do that.-R
prevents automatic rebase, so a test build won’t fail because your patch is based on an already broken commit. The other good thing is that you don’t have to remember where to submit: both the master and libreoffice-4-0 branches contain a.gitreview
file that contains the necessary server / branch information. -
Cherry-picking changes from Gerrit: I found no option for this. A cherry-pick command is generated on the web interface, but it’s more complicated than a simple
<some command> <number of the change>
. So I submitted this change to git-review itself, the next release will be able to dogit review -x <number of the change>
.
Probably the browser interface is still the best to comment (especially inline comment) and approve changes, though David even submitted a proof of concept patch for that as well.
Finally, let me just clear two myths:
-
If you use Google for OpenID login, you can have multiple OpenID accounts associated with your Gerrit login, so it’s not a problem (first I thought it is) if you use one email for Gerrit and an other one for accessing other Google services.
-
Somewhere I read that the stock LibreOffice hooks conflict with git-review: nope, git-review didn’t touch the hooks, you can use the tool without corrupting them in any way.