From 990ce9aab97802ab7da629be1b0b27ab4bcc8578 Mon Sep 17 00:00:00 2001 From: Kevin Christopher Henry Date: Thu, 12 Sep 2013 19:01:47 -0400 Subject: [PATCH] Documentation -- added instructions on working with pull requests Since non-core contributors are asked to review patches, instructions on working with pull requests were added to the Working with Git and GitHub page (based on the existing instructions in the core committers page). --- .../contributing/committing-code.txt | 2 ++ .../writing-code/working-with-git.txt | 26 ++++++++++++++++--- 2 files changed, 24 insertions(+), 4 deletions(-) diff --git a/docs/internals/contributing/committing-code.txt b/docs/internals/contributing/committing-code.txt index bc2f97a485..b81bdd2e04 100644 --- a/docs/internals/contributing/committing-code.txt +++ b/docs/internals/contributing/committing-code.txt @@ -34,6 +34,8 @@ Decisions on new committers will follow the process explained in existing committer privately. Public requests for commit access are potential flame-war starters, and will simply be ignored. +.. _handling-pull-requests: + Handling pull requests ---------------------- diff --git a/docs/internals/contributing/writing-code/working-with-git.txt b/docs/internals/contributing/writing-code/working-with-git.txt index 32fc459e70..65613efcdb 100644 --- a/docs/internals/contributing/writing-code/working-with-git.txt +++ b/docs/internals/contributing/writing-code/working-with-git.txt @@ -212,7 +212,7 @@ This way your branch will contain only commits related to its topic, which makes squashing easier. After review ------------- +~~~~~~~~~~~~ It is unusual to get any non-trivial amount of code into core without changes requested by reviewers. In this case, it is often a good idea to add the @@ -225,7 +225,8 @@ commits, you would run:: git rebase -i HEAD~2 -Squash the second commit into the first. Write a commit message along the lines of:: +Squash the second commit into the first. Write a commit message along the lines +of:: Made changes asked in review by @@ -239,8 +240,25 @@ the public commits during the rebase, you should not need to force-push:: Your pull request should now contain the new commit too. -Note that the committer is likely to squash the review commit into the previous commit -when committing the code. +Note that the committer is likely to squash the review commit into the previous +commit when committing the code. + +Working on a patch +------------------ + +One of the ways that developers can contribute to Django is by reviewing +patches. Those patches will typically exist as pull requests on GitHub and +can be easily integrated into your local repository:: + + git checkout -b pull_xxxxx upstream/master + curl https://github.com/django/django/pull/xxxxx.patch | git am + +This will create a new branch and then apply the changes from the pull request +to it. At this point you can run the tests or do anything else you need to +do to investigate the quality of the patch. + +For more detail on working with pull requests see the +:ref:`guidelines for committers `. Summary -------