Sep 28, 2017 · Sep 6, 2017 · Sep 7, 2017 · Sep 7, 2017 · Sep 7, 2017 · Sep 7, 2017
diff --git a/committing.rst b/committing.rst
 Patch checklist
 '''''''''''''''

 Along with running the tests, a simple automated patch checklist, ``patchcheck``,
 guides a developer through the common patch generation checks. To run
 ``patchcheck``:

   On *UNIX* (including Mac OS X)::

      make patchcheck

   On *Windows* (after any successful build)::

      python.bat Tools/scripts/patchcheck.py

 The automated patch checklist runs through:

 * Are there any whitespace problems in Python files?
  (using ``Tools/scripts/reindent.py``)
 * Are there any whitespace problems in C files?
 * Are there any whitespace problems in the documentation?
  (using ``Tools/scripts/reindent-rst.py``)
 * Has the documentation been updated?
 * Has the test suite been updated?
 * Has an entry under ``Misc/NEWS.d/next`` been added?
 * Has ``Misc/ACKS`` been updated?
 * Has ``configure`` been regenerated, if necessary?
 * Has ``pyconfig.h.in`` been regenerated, if necessary?

 The automated patch check doesn't actually *answer* all of these
 questions. Aside from the whitespace checks, the tool is
 a memory aid for the various elements that can go into
 making a complete patch.


 Commit Style
 ------------

 .. move this to pullrequest

 Once a change patch is ready and tested, it can be committed to the repository.
 We usually prefer to put a whole feature or bugfix into a single commit, but no
 more.  In particular:

 * Do **not** fix more than one issue in the same commit (except, of course, if
  one code change fixes all of them).
 * Do **not** do cosmetic changes to unrelated code in the same commit as some
  feature/bugfix.

 It is of course okay to pile up several commits to one branch and merge them
 into another in one commit.
 You should also :ref:`run patchcheck <patchcheck>` to perform a quick
 sanity check on the changes.


 Handling Others' Code
 unprocessed.)


 Commit Messages
 ---------------

 .. move to pullrequest

 Every commit has a commit message to document why a change was made and to
 communicate that reason to other core developers. Python core developers have
 developed a standard way of formatting commit messages that everyone is
 expected to follow.

 Our usual convention mimics that used in news entries (it is actually common to
 start by pasting the news entry into the commit message). The only key
 difference when compared to a news entry is the inclusion of the issue number
 as the beginning of the commit message. Here is an example::

   bpo-42: the spam module is now more spammy.

   The spam module sporadically came up short on spam. This change
   raises the amount of spam in the module by making it more spammy.

   Thanks to Monty Python for the patch.

 The first line or sentence is meant to be a dense, to-the-point explanation
 of what the purpose of the commit is.  If this is not enough detail for a commit,
 a new paragraph(s) can be added to explain in proper depth what has happened
 (detail should be good enough that a core developer reading the commit message
 understands the justification for the change).  Also, if a non-core developer
 contributed to the resolution, it is good practice to credit them.



 Working with Git_
 =================
Original file line number	Diff line number	Diff line change
Expand Up		@@ -57,54 +57,8 @@ passes before merging any code changes.
		Patch checklist
		'''''''''''''''

		Along with running the tests, a simple automated patch checklist, ``patchcheck``,
		guides a developer through the common patch generation checks. To run
		``patchcheck``:

		On UNIX (including Mac OS X)::

		make patchcheck

		On Windows (after any successful build)::

		python.bat Tools/scripts/patchcheck.py

		The automated patch checklist runs through:

		* Are there any whitespace problems in Python files?
		(using ``Tools/scripts/reindent.py``)
		* Are there any whitespace problems in C files?
		* Are there any whitespace problems in the documentation?
		(using ``Tools/scripts/reindent-rst.py``)
		* Has the documentation been updated?
		* Has the test suite been updated?
		* Has an entry under ``Misc/NEWS.d/next`` been added?
		* Has ``Misc/ACKS`` been updated?
		* Has ``configure`` been regenerated, if necessary?
		* Has ``pyconfig.h.in`` been regenerated, if necessary?

		The automated patch check doesn't actually answer all of these
		questions. Aside from the whitespace checks, the tool is
		a memory aid for the various elements that can go into
		making a complete patch.
Copy link MemberAuthor ezio-melottiSep 7, 2017 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. This has been moved to the pullrequest page.


		Commit Style
		------------

		.. move this to pullrequest

		Once a change patch is ready and tested, it can be committed to the repository.
		We usually prefer to put a whole feature or bugfix into a single commit, but no
		more. In particular:

		* Do not fix more than one issue in the same commit (except, of course, if
		one code change fixes all of them).
		* Do not do cosmetic changes to unrelated code in the same commit as some
		feature/bugfix.

		It is of course okay to pile up several commits to one branch and merge them
		into another in one commit.
Copy link MemberAuthor ezio-melottiSep 7, 2017 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. This has been moved to pullrequest and combined with the next red chunk.
		You should also :ref:`run patchcheck <patchcheck>` to perform a quick
		sanity check on the changes.


		Handling Others' Code
Expand DownExpand Up		@@ -238,37 +192,6 @@ allowed here because news entries are meant to be as readable as possible
		unprocessed.)


		Commit Messages
		---------------

		.. move to pullrequest

		Every commit has a commit message to document why a change was made and to
		communicate that reason to other core developers. Python core developers have
		developed a standard way of formatting commit messages that everyone is
		expected to follow.

		Our usual convention mimics that used in news entries (it is actually common to
		start by pasting the news entry into the commit message). The only key
		difference when compared to a news entry is the inclusion of the issue number
		as the beginning of the commit message. Here is an example::

		bpo-42: the spam module is now more spammy.

		The spam module sporadically came up short on spam. This change
		raises the amount of spam in the module by making it more spammy.

		Thanks to Monty Python for the patch.

		The first line or sentence is meant to be a dense, to-the-point explanation
		of what the purpose of the commit is. If this is not enough detail for a commit,
		a new paragraph(s) can be added to explain in proper depth what has happened
		(detail should be good enough that a core developer reading the commit message
		understands the justification for the change). Also, if a non-core developer
		contributed to the resolution, it is good practice to credit them.



Copy link MemberAuthor ezio-melottiSep 7, 2017 Choose a reason for hiding this comment The reason will be displayed to describe this comment to others.Learn more. This has been combined with the previous chunk.
		Working with Git_
		=================

Expand Down