Skip to content

Commit

Permalink
Documentation -- added instructions on working with pull requests
Browse files Browse the repository at this point in the history
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).
  • Loading branch information
marfire authored and timgraham committed Sep 13, 2013
1 parent c1ec089 commit 990ce9a
Show file tree
Hide file tree
Showing 2 changed files with 24 additions and 4 deletions.
2 changes: 2 additions & 0 deletions docs/internals/contributing/committing-code.txt
Expand Up @@ -34,6 +34,8 @@ Decisions on new committers will follow the process explained in
existing committer privately. Public requests for commit access are potential existing committer privately. Public requests for commit access are potential
flame-war starters, and will simply be ignored. flame-war starters, and will simply be ignored.


.. _handling-pull-requests:

Handling pull requests Handling pull requests
---------------------- ----------------------


Expand Down
26 changes: 22 additions & 4 deletions docs/internals/contributing/writing-code/working-with-git.txt
Expand Up @@ -212,7 +212,7 @@ This way your branch will contain only commits related to its topic, which
makes squashing easier. makes squashing easier.


After review After review
------------ ~~~~~~~~~~~~


It is unusual to get any non-trivial amount of code into core without changes 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 requested by reviewers. In this case, it is often a good idea to add the
Expand All @@ -225,7 +225,8 @@ commits, you would run::


git rebase -i HEAD~2 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 <reviewer> Made changes asked in review by <reviewer>


Expand All @@ -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. 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 Note that the committer is likely to squash the review commit into the previous
when committing the code. 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 <handling-pull-requests>`.


Summary Summary
------- -------
Expand Down

0 comments on commit 990ce9a

Please sign in to comment.