From befaec1e56e70582249f6cd4a5f9de5c012ad718 Mon Sep 17 00:00:00 2001 From: Mike Frysinger Date: Tue, 16 Aug 2016 00:08:37 -0400 Subject: improve docs Change-Id: Ide4008f09c2f17f8fb3d85dfffe94544abfdd6a6 --- README.md | 14 ++++++ SUBMITTING_PATCHES | 115 -------------------------------------------------- SUBMITTING_PATCHES.md | 115 ++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 129 insertions(+), 115 deletions(-) create mode 100644 README.md delete mode 100644 SUBMITTING_PATCHES create mode 100644 SUBMITTING_PATCHES.md diff --git a/README.md b/README.md new file mode 100644 index 00000000..e35f8e99 --- /dev/null +++ b/README.md @@ -0,0 +1,14 @@ +# repo + +Repo is a tool built on top of Git. Repo helps manage many Git repositories, +does the uploads to revision control systems, and automates parts of the +development workflow. Repo is not meant to replace Git, only to make it +easier to work with Git. The repo command is an executable Python script +that you can put anywhere in your path. + +* Homepage: https://code.google.com/p/git-repo/ +* Bug reports: https://code.google.com/p/git-repo/issues/ +* Source: https://code.google.com/p/git-repo/ +* Overview: https://source.android.com/source/developing.html +* Docs: https://source.android.com/source/using-repo.html +* [Submitting patches](./SUBMITTING_PATCHES.md) diff --git a/SUBMITTING_PATCHES b/SUBMITTING_PATCHES deleted file mode 100644 index 8656ee7d..00000000 --- a/SUBMITTING_PATCHES +++ /dev/null @@ -1,115 +0,0 @@ -Short Version: - - - Make small logical changes. - - Provide a meaningful commit message. - - Check for coding errors with pylint - - Make sure all code is under the Apache License, 2.0. - - Publish your changes for review. - - Make corrections if requested. - - Verify your changes on gerrit so they can be submitted. - - git push https://gerrit-review.googlesource.com/git-repo HEAD:refs/for/master - - -Long Version: - -I wanted a file describing how to submit patches for repo, -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 for coding errors with pylint - -Run pylint on changed modules using the provided configuration: - - pylint --rcfile=.pylintrc file.py - - -(3) Check the license - -repo 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. - - -(4) 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 an HTTP password to authenticate: - - https://gerrit-review.googlesource.com/new-password - -Ensure that you have the local commit hook installed to automatically -add a ChangeId to your commits: - - curl -Lo `git rev-parse --git-dir`/hooks/commit-msg https://gerrit-review.googlesource.com/tools/hooks/commit-msg - chmod +x `git rev-parse --git-dir`/hooks/commit-msg - -If you have already committed your changes you will need to amend the commit -to get the ChangeId added. - - git commit --amend - -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-review.googlesource.com/git-repo - 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. - - -(5) Make changes if requested - -The project maintainer who reviews your changes might request changes to your -commit. If you make the requested changes you will need to amend your commit -and push it to the review server again. - - -(6) Verify your changes on gerrit - -After you receive a Code-Review+2 from the maintainer, select the Verified -button on the gerrit page for the change. This verifies that you have tested -your changes and notifies the maintainer that they are ready to be submitted. -The maintainer will then submit your changes to the repository. diff --git a/SUBMITTING_PATCHES.md b/SUBMITTING_PATCHES.md new file mode 100644 index 00000000..085ae06a --- /dev/null +++ b/SUBMITTING_PATCHES.md @@ -0,0 +1,115 @@ +# Short Version + + - Make small logical changes. + - Provide a meaningful commit message. + - Check for coding errors with pylint + - Make sure all code is under the Apache License, 2.0. + - Publish your changes for review. + - Make corrections if requested. + - Verify your changes on gerrit so they can be submitted. + + `git push https://gerrit-review.googlesource.com/git-repo HEAD:refs/for/master` + + +# Long Version + +I wanted a file describing how to submit patches for repo, +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. + + +## 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. + + +## Check for coding errors with pylint + +Run pylint on changed modules using the provided configuration: + + pylint --rcfile=.pylintrc file.py + + +## Check the license + +repo 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. + + +## 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 an HTTP password to authenticate: + + https://gerrit-review.googlesource.com/new-password + +Ensure that you have the local commit hook installed to automatically +add a ChangeId to your commits: + + curl -Lo `git rev-parse --git-dir`/hooks/commit-msg https://gerrit-review.googlesource.com/tools/hooks/commit-msg + chmod +x `git rev-parse --git-dir`/hooks/commit-msg + +If you have already committed your changes you will need to amend the commit +to get the ChangeId added. + + git commit --amend + +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-review.googlesource.com/git-repo + 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. + + +## Make changes if requested + +The project maintainer who reviews your changes might request changes to your +commit. If you make the requested changes you will need to amend your commit +and push it to the review server again. + + +## Verify your changes on gerrit + +After you receive a Code-Review+2 from the maintainer, select the Verified +button on the gerrit page for the change. This verifies that you have tested +your changes and notifies the maintainer that they are ready to be submitted. +The maintainer will then submit your changes to the repository. -- cgit v1.2.3-54-g00ecf