From c050509f4ab531ffb062c6ad87c3f51a46f764a2 Mon Sep 17 00:00:00 2001 From: Ned Batchelder Date: Sat, 23 May 2026 10:26:07 -0400 Subject: [PATCH 1/2] Add details about merging pull requests --- core-team/committing.rst | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/core-team/committing.rst b/core-team/committing.rst index c606df3839..7830922d9e 100644 --- a/core-team/committing.rst +++ b/core-team/committing.rst @@ -35,7 +35,7 @@ to enter the public source tree. Ask yourself the following questions: Check :ref:`pull-request-lifecycle` and :ref:`helptriage` to review what is expected of a pull request. -* **Does the change break backwards-compatibility without a strong reason?** +* **Does the change break backwards compatibility without a strong reason?** :ref:`Run the entire test suite ` to make sure that everything still passes. If there is a change to the semantics, then there needs to be a strong reason, because it will cause some peoples' code to break. @@ -79,6 +79,31 @@ to enter the public source tree. Ask yourself the following questions: :ref:`what-s-new-and-news-entries` +Completing the pull request +--------------------------- + +Once the pull request is ready, you (the core team member) bring it into main. +If other people have been subtantially involved in the review, it can be good +to wait for their approval even if a core team member has already approved the +pull request. + +The CPython repo is configured to only accept squashes. You will squash the +pull request. + +Commit message +^^^^^^^^^^^^^^ + +GitHub defaults the squased commit message to a combined list of all of the +individual commit messages in the pull request. Do not leave those. They often +are too noisy and provide little context, especially since devs know their +worked will be eventually squashed, so intermediate commit messages while +working on the pull request are not interesting. + +If you think it is important, you can summarize the collaborative work that +went into the pull request, but it is not necessary. The pull request and/or +original issue are still available for detailed forensics. + + Working with Git_ ----------------- From 618d5ed81da67b2f9ad84acd36285caa8f0032a5 Mon Sep 17 00:00:00 2001 From: Ned Batchelder Date: Sat, 23 May 2026 12:54:21 -0400 Subject: [PATCH 2/2] review tweaks --- core-team/committing.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/core-team/committing.rst b/core-team/committing.rst index 7830922d9e..1209d6ae1e 100644 --- a/core-team/committing.rst +++ b/core-team/committing.rst @@ -79,11 +79,11 @@ to enter the public source tree. Ask yourself the following questions: :ref:`what-s-new-and-news-entries` -Completing the pull request ---------------------------- +Merging the pull request +------------------------ -Once the pull request is ready, you (the core team member) bring it into main. -If other people have been subtantially involved in the review, it can be good +Once the pull request is ready, you (the core team member) can merge it. +If other people have been substantially involved in the review, it can be good to wait for their approval even if a core team member has already approved the pull request. @@ -93,15 +93,15 @@ pull request. Commit message ^^^^^^^^^^^^^^ -GitHub defaults the squased commit message to a combined list of all of the +GitHub defaults the squashed commit message to a combined list of all of the individual commit messages in the pull request. Do not leave those. They often are too noisy and provide little context, especially since devs know their -worked will be eventually squashed, so intermediate commit messages while +work will be eventually squashed, so intermediate commit messages while working on the pull request are not interesting. If you think it is important, you can summarize the collaborative work that went into the pull request, but it is not necessary. The pull request and/or -original issue are still available for detailed forensics. +original issue are still available for detailed investigations of history. Working with Git_