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

See https://gerrit-review.googlesource.com/Documentation/dev-contributing.html
for full details.

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.

In order to contribute to Gerrit a Contributor License Agreement (CLA)
must be completed before contributions are accepted, see
https://gerrit-review.googlesource.com/Documentation/dev-cla.html.

All submissions to Google Open Source projects need to follow Google’s
Contributor License Agreement (CLA), in which contributors agree that
their contribution is an original work of authorship. This doesn’t
prohibit the use of coding assistance tools, but what’s submitted does
need to be a contributor’s original creation.


(3) Sending your patches.

Due to spam abuse, membership in the http://groups.google.com/group/repo-discuss
Google Group is required in order to create Gerrit changes on the
https://gerrit-review.googlesource.com Gerrit server. Ensure you've done that
before attempting git push.

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/#HTTPCredentials

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.