Gerrit Caveats and Hints: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
[[Category:Developing_Qt::Guidelines]] | |||
= | = 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 <code>{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&quot;. That way it is easier to amend commits without invalidating unrelated reviews. | |||
* As a reviewer, do not be too trigger-happy with the "stage&quot; button. Allow other reviewers to do their job as well, especially when domain experts were invited. | |||
* Don't do "fake&quot; 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&quot;), then don't. If needed, refer to the Maintainer Priviledge codified in the [[Commit Policy]]. | |||
=== Useful Gerrit Queries === | |||
=== | |||
Revision as of 10:23, 24 February 2015
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