Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

[1.5.x] Documentation -- added instructions on working with pull requ…

…ests

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).

Backport of 990ce9a from master
  • Loading branch information...
commit 61867e226dda35741ba363da9f5859007e4381bc 1 parent 169594f
Kevin Christopher Henry authored September 12, 2013 timgraham committed September 13, 2013
2  docs/internals/contributing/committing-code.txt
@@ -34,6 +34,8 @@ Decisions on new committers will follow the process explained in
34 34
 existing committer privately. Public requests for commit access are potential
35 35
 flame-war starters, and will simply be ignored.
36 36
 
  37
+.. _handling-pull-requests:
  38
+
37 39
 Handling pull requests
38 40
 ----------------------
39 41
 
26  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
212 212
 makes squashing easier.
213 213
 
214 214
 After review
215  
-------------
  215
+~~~~~~~~~~~~
216 216
 
217 217
 It is unusual to get any non-trivial amount of code into core without changes
218 218
 requested by reviewers. In this case, it is often a good idea to add the
@@ -225,7 +225,8 @@ commits, you would run::
225 225
 
226 226
     git rebase -i HEAD~2
227 227
 
228  
-Squash the second commit into the first. Write a commit message along the lines of::
  228
+Squash the second commit into the first. Write a commit message along the lines
  229
+of::
229 230
 
230 231
     Made changes asked in review by <reviewer>
231 232
 
@@ -239,8 +240,25 @@ the public commits during the rebase, you should not need to force-push::
239 240
 
240 241
 Your pull request should now contain the new commit too.
241 242
 
242  
-Note that the committer is likely to squash the review commit into the previous commit
243  
-when committing the code.
  243
+Note that the committer is likely to squash the review commit into the previous
  244
+commit when committing the code.
  245
+
  246
+Working on a patch
  247
+------------------
  248
+
  249
+One of the ways that developers can contribute to Django is by reviewing
  250
+patches. Those patches will typically exist as pull requests on GitHub and
  251
+can be easily integrated into your local repository::
  252
+
  253
+    git checkout -b pull_xxxxx upstream/master
  254
+    curl https://github.com/django/django/pull/xxxxx.patch | git am
  255
+
  256
+This will create a new branch and then apply the changes from the pull request
  257
+to it. At this point you can run the tests or do anything else you need to
  258
+do to investigate the quality of the patch.
  259
+
  260
+For more detail on working with pull requests see the
  261
+:ref:`guidelines for committers <handling-pull-requests>`.
244 262
 
245 263
 Summary
246 264
 -------

0 notes on commit 61867e2

Please sign in to comment.
Something went wrong with that request. Please try again.