blob: cba674169568cc9dd49a7cdc8bd8407a583bada0 [file] [log] [blame]
Shawn O. Pearce2d1a3962009-07-02 13:18:42 -07001Short Version:
2
3 - Make small logical changes.
4 - Provide a meaningful commit message.
5 - Make sure all code is under the Apache License, 2.0.
6 - Publish your changes for review:
7
David Pursehousea43f42f2012-08-21 16:26:07 +09008 git push https://gerrit-review.googlesource.com/git-repo HEAD:refs/for/master
Shawn O. Pearce2d1a3962009-07-02 13:18:42 -07009
10
11Long Version:
12
13I wanted a file describing how to submit patches for repo,
14so I started with the one found in the core Git distribution
15(Documentation/SubmittingPatches), which itself was based on the
16patch submission guidelines for the Linux kernel.
17
18However there are some differences, so please review and familiarize
19yourself with the following relevant bits:
20
21
22(1) Make separate commits for logically separate changes.
23
24Unless your patch is really trivial, you should not be sending
25out a patch that was generated between your working tree and your
26commit head. Instead, always make a commit with complete commit
27message and generate a series of patches from your repository.
28It is a good discipline.
29
30Describe the technical detail of the change(s).
31
32If your description starts to get too long, that's a sign that you
33probably need to split up your commit to finer grained pieces.
34
35
36(2) Check the license
37
38repo is licensed under the Apache License, 2.0.
39
40Because of this licensing model *every* file within the project
41*must* list the license that covers it in the header of the file.
42Any new contributions to an existing file *must* be submitted under
43the current license of that file. Any new files *must* clearly
44indicate which license they are provided under in the file header.
45
46Please verify that you are legally allowed and willing to submit your
47changes under the license covering each file *prior* to submitting
48your patch. It is virtually impossible to remove a patch once it
49has been applied and pushed out.
50
51
52(3) Sending your patches.
53
54Do not email your patches to anyone.
55
56Instead, login to the Gerrit Code Review tool at:
57
Shawn O. Pearce9b017da2012-02-28 18:53:12 -080058 https://gerrit-review.googlesource.com/
Shawn O. Pearce2d1a3962009-07-02 13:18:42 -070059
60Ensure you have completed one of the necessary contributor
61agreements, providing documentation to the project maintainers that
62they have right to redistribute your work under the Apache License:
63
Shawn O. Pearce9b017da2012-02-28 18:53:12 -080064 https://gerrit-review.googlesource.com/#/settings/agreements
Shawn O. Pearce2d1a3962009-07-02 13:18:42 -070065
Shawn O. Pearce9b017da2012-02-28 18:53:12 -080066Ensure you have obtained an HTTP password to authenticate:
Shawn O. Pearce2d1a3962009-07-02 13:18:42 -070067
Shawn O. Pearce9b017da2012-02-28 18:53:12 -080068 https://gerrit-review.googlesource.com/new-password
Shawn O. Pearce2d1a3962009-07-02 13:18:42 -070069
Shawn O. Pearce9b017da2012-02-28 18:53:12 -080070Push your patches over HTTPS to the review server, possibly through
Shawn O. Pearce2d1a3962009-07-02 13:18:42 -070071a remembered remote to make this easier in the future:
72
Shawn O. Pearce9b017da2012-02-28 18:53:12 -080073 git config remote.review.url https://gerrit-review.googlesource.com/git-repo
David Pursehousea43f42f2012-08-21 16:26:07 +090074 git config remote.review.push HEAD:refs/for/master
Shawn O. Pearce2d1a3962009-07-02 13:18:42 -070075
76 git push review
77
78You will be automatically emailed a copy of your commits, and any
79comments made by the project maintainers.