Gerrit Caveats and Hints

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

Gerrit Caveats and Hints

Dos and Don'ts

• Do not reply to review comments by mail. It hurts collaboration (as the mails are not publicaly archived). The correct way is hitting the "review" button and adding followup comments. If you want to reply to particular inline comments, open the diff view for the patchset the comments pertain to and use the reply buttons there (note that you still need to use the "review" button (of the right patchset!) to actually submit the comments).
• As an author, do not rebase your commits unless necessary, as that makes inter-patchset-diffs completely useless. Use rebase -i HEAD~n rather than rebase -i {u} when you reshuffle commits and you fetched origin meanwhile. Do not pull for no good reason. When you rebased, try to push as little as possible (HEAD~n:refs/for/foo) to avoid invalidating previous reviews.
• When you make multiple unrelated commits, it is best to throw away (reset —hard HEAD~n) the already pushed ones or make a new branch for each "topic". That way it is easier to amend commits without invalidating unrelated reviews.
• As a reviewer, do not be too trigger-happy with the "stage" button. Allow other reviewers to do their job as well, especially when domain experts were invited.
• Don't do "fake" reviews. If you cannot honestly give a +2 (i.e., "I fully understand that patch and its implications, and I take the blame if it breaks"), then don't. If needed, refer to the Maintainer Priviledge codified in the Commit Policy.

Useful Gerrit Queries