From d45c401bb203cf8640a68f01239704508d083d5c Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Tue, 26 Jan 2016 17:15:31 -0800 Subject: [PATCH] Clarify why cherry-picking is preferred in PEP 512 --- pep-0512.txt | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/pep-0512.txt b/pep-0512.txt index 014461bcb..86c210731 100644 --- a/pep-0512.txt +++ b/pep-0512.txt @@ -788,6 +788,13 @@ handled. With a cherry-picking workflow, the main commit could proceed while postponing the merge-failing cherry-picks. This allows for possibly distributing the work of managing conflicting merges. +Lastly, cherry-picking should help avoid merge races. Currently, when +one is doing work that spans branches, it takes time to commit in the +older branch, possibly push to another clone representing the +``default`` branch, merge the change, and then push upstream. +Cherry-picking should decouple this so that you don't have to rush +your multi-branch changes as the cherry-pick can be done separately. + Deriving ``Misc/NEWS`` from the commit logs ------------------------------------------- As part of the discussion surrounding `Handling Misc/NEWS`_, the