Only committers have the ability to commit your change, so make sure you work with one during code review to get your changes committed.
If you are a committer, here are some guidelines for committing changes:
- Check the JIRA ticket: make sure there is no further discussion needed regarding the approach used in the patch.
- Follow the format of commit messages: we currently do not leverage
any tooling to enforce the format of messages, so:
a. Be clear and explicit in the commit message.
b. Include the link to the review (this will be done automatically if
support/post-reviews.pyfor your own changes and
support/apply-review.shfor committing changes from others). Be sure to clean up the commit message when pulling in changes from others. c. Use 72 character columns. Note that we don't always have a 50 character or less summary because that restriction tends to cause people to write poorly.
- Keep the 'Author' intact:
support/apply-review.shwill handle this for you, but be careful when rebasing or ammending.
- Never ever commit a merge: always rebase instead, as appropriate. Likewise, never 'force push'.
- Don't break the build: we support Linux and Mac OS X, however not all configurations are being tested in Jenkins, so be aware of that. Also, pay attention to the Jenkins review bot if it flags a review as breaking the build. Note that if you do break the build, the fixes are often small and inconsequential so don't worry about going through a review cycle for that, just fix things (but don't take that as a license to "wait until the build fails to fix things").