072794767b
Add a step to SUBMITTING_PATCHES to ensure each commit message has a Change-Id. Change-Id: Ib44bc519538e304dddd6332d4a99034fc56638b3
88 lines
3.0 KiB
Plaintext
88 lines
3.0 KiB
Plaintext
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.
|