|  | Short Version: | 
|  |  | 
|  | - Make small logical changes. | 
|  | - Provide a meaningful commit message. | 
|  | - Make sure all code is under the Apache License, 2.0. | 
|  | - 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 | 
|  |  | 
|  | 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. |