Development/gerrit
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
This is the entry page on the code review tool gerrit.libreoffice.org and how to use it in LibreOffice.
Setting Yourself Up For Gerrit
See Setting yourself up for gerrit.
The alternative is fiddling with the manual approach, details of which can be found at Setting yourself up for gerrit - the manual way.
Sending a Patch to Gerrit
See Submit a patch for review with gerrit.
At the article Submit a patch for review with gerrit you will find a discussion of topics like:
- submitting a new version
- submitting patches as drafts
At the article Submodules you will find a discussion of submitting patches to submodules such as
- dictionaries
- helpcontent2 (for help files)
- translations
Gerrit workflow compared to GitHub/GitLab
The workflow with Gerrit patches is just as simple as GitHub/GitLab pull/merge requests, having only a different approach. With GitHub/GitLab PRs/MRs, you work in a branch and your additional changes will appear as a series of commits. With a Gerrit patch, you keep amending a single commit and your changes will appear as a series of patch sets. In addition to this, for bigger projects it is possible to create a series of patches that depend on each other (Related changes) or even to create remote feature branches.
Gerrit documentation has a Basic Gerrit walkthrough for GitHub users.
Gregory Szorc has written an essay about the problems with the GitHub/GitLab patch model. It touches upon Gerrit as well:
An interesting outlier is Gerrit, which ingests its integration requests via git push. But the way Gerrit's ingestion via git push works is fundamentally different from how pull requests work! With pull requests, you are pushing your local branch to a remote branch and a pull request is built around that remote branch. With Gerrit, your push command is like git push gerrit HEAD:refs/for/master. For the non-gurus, that HEAD:refs/for/master syntax means, push the HEAD commit (effectively the commit corresponding to the working directory) to the refs/for/master ref on the gerrit remote (the SOURCE:DEST syntax specifies a mapping of local revision identifier to remote ref). The wizard behind the curtain here is that Gerrit runs a special Git server that implements non-standard behavior for the refs/for/* refs. When you push to refs/for/master, Gerrit receives your Git push like a normal Git server would. But instead of writing a ref named refs/for/master, it takes the incoming commits and ingests them into a code review request! Gerrit will create Git refs for the pushed commits. But it mainly does that for its internal tracking (Gerrit stores all its data in Git - from Git data to review comments). And if that functionality isn't too magical for you, you can also pass parameters to Gerrit via the ref name! e.g. git push gerrit HEAD refs/for/master%private will create a private review request that requires special permissions to see. (It is debatable whether overloading the ref name for additional functionality is a good user experience for average users. But you can't argue that this isn't a cool hack!)
More on Gerrit
- see Development/gerrit/PatchReview on how to do review of patches on gerrit
- Split Patch after it was uploaded to gerrit
- Development/gerrit/CommonQueries
- Got a question? Consult the gerrit FAQ first or ask on the development mailing list. You can also take a look at the the official gerrit documentation.