SUBMITTING_PATCHES 2.7 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980
  1. Short Version:
  2. - Make small logical changes.
  3. - Provide a meaningful commit message.
  4. - Make sure all code is under the Apache License, 2.0.
  5. - Publish your changes for review:
  6. git push ssh://review.source.android.com:29418/tools/repo.git HEAD:refs/for/master
  7. Long Version:
  8. I wanted a file describing how to submit patches for repo,
  9. so I started with the one found in the core Git distribution
  10. (Documentation/SubmittingPatches), which itself was based on the
  11. patch submission guidelines for the Linux kernel.
  12. However there are some differences, so please review and familiarize
  13. yourself with the following relevant bits:
  14. (1) Make separate commits for logically separate changes.
  15. Unless your patch is really trivial, you should not be sending
  16. out a patch that was generated between your working tree and your
  17. commit head. Instead, always make a commit with complete commit
  18. message and generate a series of patches from your repository.
  19. It is a good discipline.
  20. Describe the technical detail of the change(s).
  21. If your description starts to get too long, that's a sign that you
  22. probably need to split up your commit to finer grained pieces.
  23. (2) Check the license
  24. repo is licensed under the Apache License, 2.0.
  25. Because of this licensing model *every* file within the project
  26. *must* list the license that covers it in the header of the file.
  27. Any new contributions to an existing file *must* be submitted under
  28. the current license of that file. Any new files *must* clearly
  29. indicate which license they are provided under in the file header.
  30. Please verify that you are legally allowed and willing to submit your
  31. changes under the license covering each file *prior* to submitting
  32. your patch. It is virtually impossible to remove a patch once it
  33. has been applied and pushed out.
  34. (3) Sending your patches.
  35. Do not email your patches to anyone.
  36. Instead, login to the Gerrit Code Review tool at:
  37. https://review.source.android.com/
  38. Ensure you have completed one of the necessary contributor
  39. agreements, providing documentation to the project maintainers that
  40. they have right to redistribute your work under the Apache License:
  41. https://review.source.android.com/#settings,agreements
  42. Ensure you have registered one or more SSH public keys, so you can
  43. push your commits directly over SSH:
  44. https://review.source.android.com/#settings,ssh-keys
  45. Push your patches over SSH to the review server, possibly through
  46. a remembered remote to make this easier in the future:
  47. git config remote.review.url ssh://review.source.android.com:29418/tools/repo.git
  48. git config remote.review.push HEAD:refs/for/master
  49. git push review
  50. You will be automatically emailed a copy of your commits, and any
  51. comments made by the project maintainers.