| Short Version: |
| |
| - Make small logical changes. |
| - Provide a meaningful commit message. |
| - Make sure all code is under the Apache License, 2.0. |
| - Make sure all commit messages have a Change-Id. |
| - Publish your changes for review: |
| |
| git push https://gerrit.googlesource.com/gerrit HEAD:refs/for/master |
| |
| |
| Long Version: |
| |
| I wanted a file describing how to submit patches for Gerrit, |
| so I started with the one found in the core Git distribution |
| (Documentation/SubmittingPatches), which itself was based on the |
| patch submission guidelines for the Linux kernel. |
| |
| However there are some differences, so please review and familiarize |
| yourself with the following relevant bits: |
| |
| |
| (1) Make separate commits for logically separate changes. |
| |
| Unless your patch is really trivial, you should not be sending |
| out a patch that was generated between your working tree and your |
| commit head. Instead, always make a commit with complete commit |
| message and generate a series of patches from your repository. |
| It is a good discipline. |
| |
| Describe the technical detail of the change(s). |
| |
| If your description starts to get too long, that's a sign that you |
| probably need to split up your commit to finer grained pieces. |
| |
| |
| (2) Check the license |
| |
| Gerrit Code Review is licensed under the Apache License, 2.0. |
| |
| Because of this licensing model *every* file within the project |
| *must* list the license that covers it in the header of the file. |
| Any new contributions to an existing file *must* be submitted under |
| the current license of that file. Any new files *must* clearly |
| indicate which license they are provided under in the file header. |
| |
| Please verify that you are legally allowed and willing to submit your |
| changes under the license covering each file *prior* to submitting |
| your patch. It is virtually impossible to remove a patch once it |
| has been applied and pushed out. |
| |
| |
| (3) Sending your patches. |
| |
| Do not email your patches to anyone. |
| |
| Instead, login to the Gerrit Code Review tool at: |
| |
| https://gerrit-review.googlesource.com/ |
| |
| Ensure you have completed one of the necessary contributor |
| agreements, providing documentation to the project maintainers that |
| they have right to redistribute your work under the Apache License: |
| |
| https://gerrit-review.googlesource.com/#/settings/agreements |
| |
| Ensure you have obtained a unique HTTP password to identify yourself: |
| |
| https://gerrit-review.googlesource.com/#/settings/http-password |
| |
| Ensure you have installed the commit-msg hook that automatically |
| generates and inserts a Change-Id line during "git commit". This can |
| be done from the root directory of the local Git repository: |
| |
| curl -Lo .git/hooks/commit-msg https://gerrit-review.googlesource.com/tools/hooks/commit-msg |
| chmod +x .git/hooks/commit-msg |
| |
| Push your patches over HTTPS to the review server, possibly through |
| a remembered remote to make this easier in the future: |
| |
| git config remote.review.url https://gerrit.googlesource.com/gerrit |
| git config remote.review.push HEAD:refs/for/master |
| |
| git push review |
| |
| You will be automatically emailed a copy of your commits, and any |
| comments made by the project maintainers. |