From brett at snarky.ca  Thu Oct  6 15:41:12 2016
From: brett at snarky.ca (Brett Cannon)
Date: Thu, 06 Oct 2016 19:41:12 +0000
Subject: [core-workflow] GitHub migration update
Message-ID: <CAP1=2W4L4-rvRXoT2yn08ma1XrYL9yZr8YapQpVR5QVfDim=kQ@mail.gmail.com>

As always, the master TODO list is kept at
https://www.python.org/dev/peps/pep-0512/#cpython-repo . To summarize:

   - The bugs.python.org changes have patches but they need to land
   (hopefully Maciej Szulik or R. David Murray can help with that)
   - Ned Deily and R. David said they could help with the IRC and emails to
   python-checkins at the core dev sprint last month (unless I'm remembering
   wrong :)
   - Ned said PEP 101 will get updated by him
   - sys._git is coded but awaiting a code review by Ned (and probably
   deciding if it should be in Python 3.6 or just straight into 3.7)
   - Updating hg.python.org/lookup is still needed/desired
   - Need to check if the current mirror is actually good enough to just
   keeping using to avoid breaking everyone's clone of the repository, or if
   we truly do need to fully regenerate the repo
   - Need to finish updating the devguide


So a bunch of stuff is in-progress which is great! Probably the thing that
I need the most help with ATM is updating the devguide. There's a `github`
branch at https://github.com/python/devguide/tree/github where we're trying
to eliminate or move mentions of Mercurial over to Git (see
https://github.com/python/devguide/milestone/1 for the relevant issues). We
also need to figure out exactly what git commands we want for doing squash
commits from the command-line (we will have the Squash and Merge button on
GitHub, but some people prefer a CLI and the commands that GitHub provides
are not squash ones), and we also need instructions on how to cherrypick a
change that went into master but needs to be backported to an older
version(s) of Python (I will start separate threads for that discussion).

At the core sprints last month, Ned and I talked and we agreed that we
wouldn't switch until after 3.6.0 came out so as to not risk botching the
release because of the migration. That means the switchover won't happen
any sooner than mid/late December, but luckily most of this stuff can still
be done (and tested) prior to officially switching so this doesn't need to
hold anything up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161006/137932dc/attachment.html>

From senthil at uthcode.com  Thu Oct  6 16:22:34 2016
From: senthil at uthcode.com (Senthil Kumaran)
Date: Thu, 6 Oct 2016 13:22:34 -0700
Subject: [core-workflow] GitHub migration update
In-Reply-To: <CAP1=2W4L4-rvRXoT2yn08ma1XrYL9yZr8YapQpVR5QVfDim=kQ@mail.gmail.com>
References: <CAP1=2W4L4-rvRXoT2yn08ma1XrYL9yZr8YapQpVR5QVfDim=kQ@mail.gmail.com>
Message-ID: <CAPOVWOTu2RDRTX9UQ61Qu7k2rOhw6Zi5WybP_FAy0PaH0n3tjQ@mail.gmail.com>

On Thu, Oct 6, 2016 at 12:41 PM, Brett Cannon <brett at snarky.ca> wrote:

> Need to check if the current mirror is actually good enough to just
> keeping using to avoid breaking everyone's clone of the repository, or if
> we truly do need to fully regenerate the repo


I will help here and provide a definitive answer to this. We can work
together on the timeline.

Thank you,
Senthil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161006/c8554dba/attachment.html>

From brett at snarky.ca  Thu Oct  6 16:31:29 2016
From: brett at snarky.ca (Brett Cannon)
Date: Thu, 06 Oct 2016 20:31:29 +0000
Subject: [core-workflow] GitHub migration update
In-Reply-To: <CAPOVWOTu2RDRTX9UQ61Qu7k2rOhw6Zi5WybP_FAy0PaH0n3tjQ@mail.gmail.com>
References: <CAP1=2W4L4-rvRXoT2yn08ma1XrYL9yZr8YapQpVR5QVfDim=kQ@mail.gmail.com>
 <CAPOVWOTu2RDRTX9UQ61Qu7k2rOhw6Zi5WybP_FAy0PaH0n3tjQ@mail.gmail.com>
Message-ID: <CAP1=2W5OB-_PD_80_FWxTCtcu7do8m5P8vm5h3MZkhHGzeLnZw@mail.gmail.com>

Great, thanks!

On Thu, 6 Oct 2016 at 13:22 Senthil Kumaran <senthil at uthcode.com> wrote:

>
> On Thu, Oct 6, 2016 at 12:41 PM, Brett Cannon <brett at snarky.ca> wrote:
>
> Need to check if the current mirror is actually good enough to just
> keeping using to avoid breaking everyone's clone of the repository, or if
> we truly do need to fully regenerate the repo
>
>
> I will help here and provide a definitive answer to this. We can work
> together on the timeline.
>
> Thank you,
> Senthil
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161006/574cd045/attachment.html>

From soltysh at gmail.com  Thu Oct  6 17:32:48 2016
From: soltysh at gmail.com (Maciej Szulik)
Date: Thu, 6 Oct 2016 23:32:48 +0200
Subject: [core-workflow] GitHub migration update
In-Reply-To: <CAP1=2W4L4-rvRXoT2yn08ma1XrYL9yZr8YapQpVR5QVfDim=kQ@mail.gmail.com>
References: <CAP1=2W4L4-rvRXoT2yn08ma1XrYL9yZr8YapQpVR5QVfDim=kQ@mail.gmail.com>
Message-ID: <CALC2N4aifBOrR-JVAbe-hWEv3pg7sA2V2X77QrcR_pJ=7+efug@mail.gmail.com>

On Thu, Oct 6, 2016 at 9:41 PM, Brett Cannon <brett at snarky.ca> wrote:

> As always, the master TODO list is kept at https://www.python.org/dev/
> peps/pep-0512/#cpython-repo . To summarize:
>
>    - The bugs.python.org changes have patches but they need to land
>    (hopefully Maciej Szulik or R. David Murray can help with that)
>
> I'll sync with David and Ezio about it and will keep my hand on it. I
don't have commit rights to
roundup repos ;)

>
>    -
>    - Ned Deily and R. David said they could help with the IRC and emails
>    to python-checkins at the core dev sprint last month (unless I'm
>    remembering wrong :)
>    - Ned said PEP 101 will get updated by him
>    - sys._git is coded but awaiting a code review by Ned (and probably
>    deciding if it should be in Python 3.6 or just straight into 3.7)
>    - Updating hg.python.org/lookup is still needed/desired
>    - Need to check if the current mirror is actually good enough to just
>    keeping using to avoid breaking everyone's clone of the repository, or if
>    we truly do need to fully regenerate the repo
>    - Need to finish updating the devguide
>
>
> So a bunch of stuff is in-progress which is great! Probably the thing that
> I need the most help with ATM is updating the devguide. There's a `github`
> branch at https://github.com/python/devguide/tree/github where we're
> trying to eliminate or move mentions of Mercurial over to Git (see
> https://github.com/python/devguide/milestone/1 for the relevant issues).
> We also need to figure out exactly what git commands we want for doing
> squash commits from the command-line (we will have the Squash and Merge
> button on GitHub, but some people prefer a CLI and the commands that GitHub
> provides are not squash ones), and we also need instructions on how to
> cherrypick a change that went into master but needs to be backported to an
> older version(s) of Python (I will start separate threads for that
> discussion).
>

I can create a doc describing the cherry-pick, should I post a PR against
that branch?

The general flow should be very simple, such as:
1. find the commit you want to cherry-pick
2. switch to branch you're cherry-picking to
3. git cherry-pick sha
4. fix eventual incompatibilities

With more words, that should be ok, wdyt?


>
> At the core sprints last month, Ned and I talked and we agreed that we
> wouldn't switch until after 3.6.0 came out so as to not risk botching the
> release because of the migration. That means the switchover won't happen
> any sooner than mid/late December, but luckily most of this stuff can still
> be done (and tested) prior to officially switching so this doesn't need to
> hold anything up.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161006/f95f171c/attachment-0001.html>

From brett at snarky.ca  Thu Oct  6 17:38:15 2016
From: brett at snarky.ca (Brett Cannon)
Date: Thu, 06 Oct 2016 21:38:15 +0000
Subject: [core-workflow] GitHub migration update
In-Reply-To: <CALC2N4aifBOrR-JVAbe-hWEv3pg7sA2V2X77QrcR_pJ=7+efug@mail.gmail.com>
References: <CAP1=2W4L4-rvRXoT2yn08ma1XrYL9yZr8YapQpVR5QVfDim=kQ@mail.gmail.com>
 <CALC2N4aifBOrR-JVAbe-hWEv3pg7sA2V2X77QrcR_pJ=7+efug@mail.gmail.com>
Message-ID: <CAP1=2W5XxzRKR2oU_8dF20h4vmjfNLGN7s3CVcOnAEYyc5rXtQ@mail.gmail.com>

On Thu, 6 Oct 2016 at 14:32 Maciej Szulik <soltysh at gmail.com> wrote:

> On Thu, Oct 6, 2016 at 9:41 PM, Brett Cannon <brett at snarky.ca> wrote:
>
> As always, the master TODO list is kept at
> https://www.python.org/dev/peps/pep-0512/#cpython-repo . To summarize:
>
>    - The bugs.python.org changes have patches but they need to land
>    (hopefully Maciej Szulik or R. David Murray can help with that)
>
> I'll sync with David and Ezio about it and will keep my hand on it. I
> don't have commit rights to
> roundup repos ;)
>
>
>    -
>    - Ned Deily and R. David said they could help with the IRC and emails
>    to python-checkins at the core dev sprint last month (unless I'm
>    remembering wrong :)
>    - Ned said PEP 101 will get updated by him
>    - sys._git is coded but awaiting a code review by Ned (and probably
>    deciding if it should be in Python 3.6 or just straight into 3.7)
>    - Updating hg.python.org/lookup is still needed/desired
>    - Need to check if the current mirror is actually good enough to just
>    keeping using to avoid breaking everyone's clone of the repository, or if
>    we truly do need to fully regenerate the repo
>    - Need to finish updating the devguide
>
>
> So a bunch of stuff is in-progress which is great! Probably the thing that
> I need the most help with ATM is updating the devguide. There's a `github`
> branch at https://github.com/python/devguide/tree/github where we're
> trying to eliminate or move mentions of Mercurial over to Git (see
> https://github.com/python/devguide/milestone/1 for the relevant issues).
> We also need to figure out exactly what git commands we want for doing
> squash commits from the command-line (we will have the Squash and Merge
> button on GitHub, but some people prefer a CLI and the commands that GitHub
> provides are not squash ones), and we also need instructions on how to
> cherrypick a change that went into master but needs to be backported to an
> older version(s) of Python (I will start separate threads for that
> discussion).
>
>
> I can create a doc describing the cherry-pick, should I post a PR against
> that branch?
>
> The general flow should be very simple, such as:
> 1. find the commit you want to cherry-pick
> 2. switch to branch you're cherry-picking to
> 3. git cherry-pick sha
> 4. fix eventual incompatibilities
>
> With more words, that should be ok, wdyt?
>

Yep, a PR updating
https://github.com/python/devguide/blob/github/committing.rst (rendered at
http://cpython-devguide.readthedocs.io/en/github/committing.html, issue at
https://github.com/python/devguide/issues/44) would be great! I don't think
there's anywhere else in the devguide that directly relates to commits that
must be applied to multiple versions of Python.

-Brett


>
>
>
> At the core sprints last month, Ned and I talked and we agreed that we
> wouldn't switch until after 3.6.0 came out so as to not risk botching the
> release because of the migration. That means the switchover won't happen
> any sooner than mid/late December, but luckily most of this stuff can still
> be done (and tested) prior to officially switching so this doesn't need to
> hold anything up.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161006/f9e213bf/attachment.html>

From brett at snarky.ca  Thu Oct  6 15:44:38 2016
From: brett at snarky.ca (Brett Cannon)
Date: Thu, 06 Oct 2016 19:44:38 +0000
Subject: [core-workflow] instructions for cherrypicking a change from master
Message-ID: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>

Since we're going with a cherrypicking for managing changes that apply to
multiple versions of Python, we need to come up with the set of
instructions on how to take e.g. a change committed in master and
cherrypick it into 3.6. Anyone have such a set of instructions handy?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161006/24f2e9ba/attachment.html>

From rosuav at gmail.com  Thu Oct  6 21:55:46 2016
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 7 Oct 2016 12:55:46 +1100
Subject: [core-workflow] instructions for cherrypicking a change from
 master
In-Reply-To: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
Message-ID: <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>

On Fri, Oct 7, 2016 at 6:44 AM, Brett Cannon <brett at snarky.ca> wrote:
> Since we're going with a cherrypicking for managing changes that apply to
> multiple versions of Python, we need to come up with the set of instructions
> on how to take e.g. a change committed in master and cherrypick it into 3.6.
> Anyone have such a set of instructions handy?

Check out the branch you want to cherry-pick into.
$ git checkout 3.6
Grab the commit you want
$ git cherry-pick 142a57
Make sure it looks good, and then push.

You can identify the commit in a variety of ways; if you just
committed it to master, you can identify the commit as 'master'.
(Don't confuse 'git merge master' and 'git cherry-pick master'; the
former says "merge in everything that the master branch has" or "merge
in the *content* from the master branch", while the latter says "grab
the top commit at branch master".)

If you want to, you can 'git cherry-pick -x 142a57', which will add a
linking comment to the commit that it creates, saying where it came
from.

ChrisA

From ncoghlan at gmail.com  Thu Oct  6 22:26:23 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 7 Oct 2016 12:26:23 +1000
Subject: [core-workflow] instructions for cherrypicking a change from
 master
In-Reply-To: <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
 <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
Message-ID: <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>

On 7 October 2016 at 11:55, Chris Angelico <rosuav at gmail.com> wrote:
> If you want to, you can 'git cherry-pick -x 142a57', which will add a
> linking comment to the commit that it creates, saying where it came
> from.

Recommending the use of referenced cherry picks sounds like a good idea to me.

It may also be worth linking to
https://www.python.org/dev/peps/pep-0512/#commit-multi-release-changes-in-bugfix-branch-first
from this section of the devguide to help explain why we recommend
using the "work on master, cherry pick to maintenance branches"
approach.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From rosuav at gmail.com  Thu Oct  6 22:28:15 2016
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 7 Oct 2016 13:28:15 +1100
Subject: [core-workflow] instructions for cherrypicking a change from
 master
In-Reply-To: <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
 <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
 <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>
Message-ID: <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>

On Fri, Oct 7, 2016 at 1:26 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 7 October 2016 at 11:55, Chris Angelico <rosuav at gmail.com> wrote:
>> If you want to, you can 'git cherry-pick -x 142a57', which will add a
>> linking comment to the commit that it creates, saying where it came
>> from.
>
> Recommending the use of referenced cherry picks sounds like a good idea to me.
>
> It may also be worth linking to
> https://www.python.org/dev/peps/pep-0512/#commit-multi-release-changes-in-bugfix-branch-first
> from this section of the devguide to help explain why we recommend
> using the "work on master, cherry pick to maintenance branches"
> approach.

git checkout master
git cherry-pick footnote
git show

Check out the branch you want to cherry-pick into.
$ git checkout 3.6
Grab the commit you want
$ git cherry-pick -x 142a57
Make sure it looks good, and then push.

:)

ChrisA

From ncoghlan at gmail.com  Thu Oct  6 23:10:26 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 7 Oct 2016 13:10:26 +1000
Subject: [core-workflow] instructions for cherrypicking a change from
 master
In-Reply-To: <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
 <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
 <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>
 <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>
Message-ID: <CADiSq7ezp9iqavevczRVuig+A=ORFZ5BSdAupfVXGsbuwnG0_A@mail.gmail.com>

On 7 October 2016 at 12:28, Chris Angelico <rosuav at gmail.com> wrote:
> git checkout master
> git cherry-pick footnote
> git show
>
> Check out the branch you want to cherry-pick into.
> $ git checkout 3.6
> Grab the commit you want
> $ git cherry-pick -x 142a57
> Make sure it looks good, and then push.

That note about "make sure it looks good" reminded me that "make
patchcheck" is going to need updating to handle git, which means
updating Tools/scripts/patchcheck.py

Brett, how would you like that extra task captured - PR to PEP 512?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From zachary.ware+pydev at gmail.com  Thu Oct  6 23:26:27 2016
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Thu, 6 Oct 2016 22:26:27 -0500
Subject: [core-workflow] instructions for cherrypicking a change from
 master
In-Reply-To: <CADiSq7ezp9iqavevczRVuig+A=ORFZ5BSdAupfVXGsbuwnG0_A@mail.gmail.com>
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
 <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
 <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>
 <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>
 <CADiSq7ezp9iqavevczRVuig+A=ORFZ5BSdAupfVXGsbuwnG0_A@mail.gmail.com>
Message-ID: <CAKJDb-NbeGeirW_tsjYgr+2jUZ5WR5boU7QgJGNS=J+O7qcQ0Q@mail.gmail.com>

On Thu, Oct 6, 2016 at 10:10 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> That note about "make sure it looks good" reminded me that "make
> patchcheck" is going to need updating to handle git, which means
> updating Tools/scripts/patchcheck.py
>
> Brett, how would you like that extra task captured - PR to PEP 512?

I just checked, `make patchcheck` works fine from a Git checkout.

-- 
Zach

From ncoghlan at gmail.com  Fri Oct  7 03:37:50 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 7 Oct 2016 17:37:50 +1000
Subject: [core-workflow] instructions for cherrypicking a change from
 master
In-Reply-To: <CAKJDb-NbeGeirW_tsjYgr+2jUZ5WR5boU7QgJGNS=J+O7qcQ0Q@mail.gmail.com>
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
 <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
 <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>
 <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>
 <CADiSq7ezp9iqavevczRVuig+A=ORFZ5BSdAupfVXGsbuwnG0_A@mail.gmail.com>
 <CAKJDb-NbeGeirW_tsjYgr+2jUZ5WR5boU7QgJGNS=J+O7qcQ0Q@mail.gmail.com>
Message-ID: <CADiSq7dwR2GpBiAY7jvkwq9MOtKps_WsGw7naKH-zwA7LWg1sw@mail.gmail.com>

On 7 October 2016 at 13:26, Zachary Ware <zachary.ware+pydev at gmail.com> wrote:
> On Thu, Oct 6, 2016 at 10:10 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> That note about "make sure it looks good" reminded me that "make
>> patchcheck" is going to need updating to handle git, which means
>> updating Tools/scripts/patchcheck.py
>>
>> Brett, how would you like that extra task captured - PR to PEP 512?
>
> I just checked, `make patchcheck` works fine from a Git checkout.

Could, if it basically works already, we probably don't need to note
it anywhere.

My comment was based on the fact that there are references to both
Mercurial and Mercurial Queues in the patchcheck source code, but I
didn't look in detail at what they actually do.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From brett at snarky.ca  Thu Oct  6 15:43:21 2016
From: brett at snarky.ca (Brett Cannon)
Date: Thu, 06 Oct 2016 19:43:21 +0000
Subject: [core-workflow] What instructions to give for squashing PRs from
 the CLI?
Message-ID: <CAP1=2W6E2kQ_KHDp508mquK-PgqO_GVFcaHR3e9C3OhZgy9VMw@mail.gmail.com>

While we will use GitHub's Squash and Merge button for PRs, that doesn't
meant everyone will want to use it; some people just prefer using a CLI.
That means we need to come up with a set of instructions on how to take a
GitHub PR and perform a squash commit manually at the CLI (committing a
patch from bugs.python.org is simply since there's no squashing to do).
Anyone have that set of commands handy?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161006/4e5f8aff/attachment.html>

From phd at phdru.name  Fri Oct  7 07:35:37 2016
From: phd at phdru.name (Oleg Broytman)
Date: Fri, 7 Oct 2016 13:35:37 +0200
Subject: [core-workflow] What instructions to give for squashing PRs
 from the CLI?
In-Reply-To: <CAP1=2W6E2kQ_KHDp508mquK-PgqO_GVFcaHR3e9C3OhZgy9VMw@mail.gmail.com>
References: <CAP1=2W6E2kQ_KHDp508mquK-PgqO_GVFcaHR3e9C3OhZgy9VMw@mail.gmail.com>
Message-ID: <20161007113537.GA30663@phdru.name>

On Thu, Oct 06, 2016 at 07:43:21PM +0000, Brett Cannon <brett at snarky.ca> wrote:
> While we will use GitHub's Squash and Merge button for PRs, that doesn't
> meant everyone will want to use it; some people just prefer using a CLI.
> That means we need to come up with a set of instructions on how to take a
> GitHub PR and perform a squash commit manually at the CLI (committing a
> patch from bugs.python.org is simply since there's no squashing to do).
> Anyone have that set of commands handy?

It's something like::

    $ git fetch github pull/$ID/head:$BRANCHNAME
    $ git checkout master
    $ git merge --squash $BRANCHNAME
    $ git branch -d $BRANCHNAME

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd at phdru.name
           Programmers don't die, they just GOSUB without RETURN.

From soltysh at gmail.com  Fri Oct  7 16:10:43 2016
From: soltysh at gmail.com (Maciej Szulik)
Date: Fri, 7 Oct 2016 22:10:43 +0200
Subject: [core-workflow] What instructions to give for squashing PRs
 from the CLI?
In-Reply-To: <20161007113537.GA30663@phdru.name>
References: <CAP1=2W6E2kQ_KHDp508mquK-PgqO_GVFcaHR3e9C3OhZgy9VMw@mail.gmail.com>
 <20161007113537.GA30663@phdru.name>
Message-ID: <CALC2N4apB2+nuF5b=VKENP7WzAWH9QCinj7H=U00q4HageiMZg@mail.gmail.com>

I usually go with the visual version which goes like this:

1. git rebase -i HEAD~2 (where 2 means here 2 previous commits)
2. now in editor you can pick which commit can be squashed to which (all
nicely described)
3. mark 2nd commit, which will be squashed to previous with squash, write
changes and exit
4. now you can tweak the log message (both are shown), write changes and
exit

You're left with just single commit.


On Fri, Oct 7, 2016 at 1:35 PM, Oleg Broytman <phd at phdru.name> wrote:

> On Thu, Oct 06, 2016 at 07:43:21PM +0000, Brett Cannon <brett at snarky.ca>
> wrote:
> > While we will use GitHub's Squash and Merge button for PRs, that doesn't
> > meant everyone will want to use it; some people just prefer using a CLI.
> > That means we need to come up with a set of instructions on how to take a
> > GitHub PR and perform a squash commit manually at the CLI (committing a
> > patch from bugs.python.org is simply since there's no squashing to do).
> > Anyone have that set of commands handy?
>
> It's something like::
>
>     $ git fetch github pull/$ID/head:$BRANCHNAME
>     $ git checkout master
>     $ git merge --squash $BRANCHNAME
>     $ git branch -d $BRANCHNAME
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            phd at phdru.name
>            Programmers don't die, they just GOSUB without RETURN.
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161007/542ec4da/attachment.html>

From soltysh at gmail.com  Fri Oct  7 17:31:34 2016
From: soltysh at gmail.com (Maciej Szulik)
Date: Fri, 7 Oct 2016 23:31:34 +0200
Subject: [core-workflow] instructions for cherrypicking a change from
 master
In-Reply-To: <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
 <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
 <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>
 <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>
Message-ID: <CALC2N4ZEWuewVssKAGy6t6vTZVEnyjJ7XS8nUp=NwZF6U-ZBQw@mail.gmail.com>

On Fri, Oct 7, 2016 at 4:28 AM, Chris Angelico <rosuav at gmail.com> wrote:

> On Fri, Oct 7, 2016 at 1:26 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > On 7 October 2016 at 11:55, Chris Angelico <rosuav at gmail.com> wrote:
> >> If you want to, you can 'git cherry-pick -x 142a57', which will add a
> >> linking comment to the commit that it creates, saying where it came
> >> from.
> >
> > Recommending the use of referenced cherry picks sounds like a good idea
> to me.
> >
> > It may also be worth linking to
> > https://www.python.org/dev/peps/pep-0512/#commit-multi-
> release-changes-in-bugfix-branch-first
> > from this section of the devguide to help explain why we recommend
> > using the "work on master, cherry pick to maintenance branches"
> > approach.
>
> git checkout master
> git cherry-pick footnote
> git show
>
> Check out the branch you want to cherry-pick into.
> $ git checkout 3.6
> Grab the commit you want
> $ git cherry-pick -x 142a57
> Make sure it looks good, and then push.
>

There's one nit with that cherry-pick, it already creates the commit, and
current
description states you should create a commit after running tests [1].
Although
in my update [2] I decided to go with automatic commit, to leverage -x
option.

[1]
http://cpython-devguide.readthedocs.io/en/github/committing.html#merging-between-different-branches-within-the-same-major-version
[2] https://github.com/python/devguide/pull/57


>
> :)
>
> ChrisA
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161007/864eab5d/attachment.html>

From rosuav at gmail.com  Fri Oct  7 17:37:56 2016
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 8 Oct 2016 08:37:56 +1100
Subject: [core-workflow] instructions for cherrypicking a change from
 master
In-Reply-To: <CALC2N4ZEWuewVssKAGy6t6vTZVEnyjJ7XS8nUp=NwZF6U-ZBQw@mail.gmail.com>
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
 <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
 <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>
 <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>
 <CALC2N4ZEWuewVssKAGy6t6vTZVEnyjJ7XS8nUp=NwZF6U-ZBQw@mail.gmail.com>
Message-ID: <CAPTjJmr0VWjL58oXyApHLXvdqs2Xb2a_K_jc0MhZtC-y_OBKcw@mail.gmail.com>

On Sat, Oct 8, 2016 at 8:31 AM, Maciej Szulik <soltysh at gmail.com> wrote:
> There's one nit with that cherry-pick, it already creates the commit, and
> current
> description states you should create a commit after running tests [1].
>
> [1]
> http://cpython-devguide.readthedocs.io/en/github/committing.html#merging-between-different-branches-within-the-same-major-version

Not sure that that need be a problem. You've already run the tests on
the other branch, presumably, so the chances of a test failure are
low; most of the time, it'll be "cherry-pick, test, push", and very
occasionally, it'll be "cherry-pick, test, oops failures, reset or
amend". As long as you don't push, there's nothing permanent in the
commit.

ChrisA

From soltysh at gmail.com  Fri Oct  7 18:14:52 2016
From: soltysh at gmail.com (Maciej Szulik)
Date: Sat, 8 Oct 2016 00:14:52 +0200
Subject: [core-workflow] instructions for cherrypicking a change from
 master
In-Reply-To: <CAPTjJmr0VWjL58oXyApHLXvdqs2Xb2a_K_jc0MhZtC-y_OBKcw@mail.gmail.com>
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
 <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
 <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>
 <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>
 <CALC2N4ZEWuewVssKAGy6t6vTZVEnyjJ7XS8nUp=NwZF6U-ZBQw@mail.gmail.com>
 <CAPTjJmr0VWjL58oXyApHLXvdqs2Xb2a_K_jc0MhZtC-y_OBKcw@mail.gmail.com>
Message-ID: <CALC2N4ZC0NZUbWbo4vsYW6uz-bQf83rhOQXAJL3MDJOKOsi0PA@mail.gmail.com>

On Fri, Oct 7, 2016 at 11:37 PM, Chris Angelico <rosuav at gmail.com> wrote:

> On Sat, Oct 8, 2016 at 8:31 AM, Maciej Szulik <soltysh at gmail.com> wrote:
> > There's one nit with that cherry-pick, it already creates the commit, and
> > current
> > description states you should create a commit after running tests [1].
> >
> > [1]
> > http://cpython-devguide.readthedocs.io/en/github/
> committing.html#merging-between-different-branches-
> within-the-same-major-version
>
> Not sure that that need be a problem. You've already run the tests on
> the other branch, presumably, so the chances of a test failure are
> low; most of the time, it'll be "cherry-pick, test, push", and very
> occasionally, it'll be "cherry-pick, test, oops failures, reset or
> amend". As long as you don't push, there's nothing permanent in the
> commit.
>

Totally agree, that's why I went with that change and left the history
behind.
But run tests is still required :)


>
> ChrisA
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161008/632e7d1b/attachment-0001.html>

From rosuav at gmail.com  Fri Oct  7 18:16:16 2016
From: rosuav at gmail.com (Chris Angelico)
Date: Sat, 8 Oct 2016 09:16:16 +1100
Subject: [core-workflow] instructions for cherrypicking a change from
 master
In-Reply-To: <CALC2N4ZC0NZUbWbo4vsYW6uz-bQf83rhOQXAJL3MDJOKOsi0PA@mail.gmail.com>
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
 <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
 <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>
 <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>
 <CALC2N4ZEWuewVssKAGy6t6vTZVEnyjJ7XS8nUp=NwZF6U-ZBQw@mail.gmail.com>
 <CAPTjJmr0VWjL58oXyApHLXvdqs2Xb2a_K_jc0MhZtC-y_OBKcw@mail.gmail.com>
 <CALC2N4ZC0NZUbWbo4vsYW6uz-bQf83rhOQXAJL3MDJOKOsi0PA@mail.gmail.com>
Message-ID: <CAPTjJmpwH4LTEzxQEThv0vad=4OLyyaosWM=BZY=8GoaQ8ENRQ@mail.gmail.com>

On Sat, Oct 8, 2016 at 9:14 AM, Maciej Szulik <soltysh at gmail.com> wrote:
> Totally agree, that's why I went with that change and left the history
> behind.
> But run tests is still required :)

Oh sure. Definitely run the tests. No disagreement there :)

ChrisA

From barry at python.org  Fri Oct  7 23:23:58 2016
From: barry at python.org (Barry Warsaw)
Date: Fri, 7 Oct 2016 23:23:58 -0400
Subject: [core-workflow] What instructions to give for squashing PRs
 from the CLI?
References: <CAP1=2W6E2kQ_KHDp508mquK-PgqO_GVFcaHR3e9C3OhZgy9VMw@mail.gmail.com>
 <20161007113537.GA30663@phdru.name>
Message-ID: <20161007232358.7c3b6f8e@anarchist>

On Oct 07, 2016, at 01:35 PM, Oleg Broytman wrote:

>    $ git fetch github pull/$ID/head:$BRANCHNAME
>    $ git checkout master
>    $ git merge --squash $BRANCHNAME
>    $ git branch -d $BRANCHNAME

This works well, and is generally the instructions that GitLab provides for
local CLI merges.  A few things to note.

>    $ git fetch github pull/$ID/head:$BRANCHNAME
                 ^^^^^^
This is the remote name, so it will usually be 'origin' but it can be anything
(i.e. it's up to the local user).

>    $ git fetch github pull/$ID/head:$BRANCHNAME
                                     ^^^^^^^^^^^^
This isn't strictly necessary.  If not given, use FETCH_HEAD.  And if you want
to do some things with the branch before you merge it to master (e.g. add
NEWS, uncommit code changes to make sure that the tests prove a fix works,
etc.) then you can:

    $ git co -b $BRANCHNAME FETCH_HEAD

Of course, $BRANCHNAME can be anything you want.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161007/bc2f2dff/attachment.sig>

From barry at python.org  Fri Oct  7 23:27:34 2016
From: barry at python.org (Barry Warsaw)
Date: Fri, 7 Oct 2016 23:27:34 -0400
Subject: [core-workflow] instructions for cherrypicking a change from
 master
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
 <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
 <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>
 <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>
 <CALC2N4ZEWuewVssKAGy6t6vTZVEnyjJ7XS8nUp=NwZF6U-ZBQw@mail.gmail.com>
Message-ID: <20161007232734.53d4dc89@anarchist>

On Oct 07, 2016, at 11:31 PM, Maciej Szulik wrote:

>There's one nit with that cherry-pick, it already creates the commit, and
>current description states you should create a commit after running tests
>[1].

You can also use cherry-pick -n/--no-commit.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161007/84dd4eb4/attachment.sig>

From ncoghlan at gmail.com  Sat Oct  8 22:43:10 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 9 Oct 2016 12:43:10 +1000
Subject: [core-workflow] instructions for cherrypicking a change from
 master
In-Reply-To: <20161007232734.53d4dc89@anarchist>
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
 <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
 <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>
 <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>
 <CALC2N4ZEWuewVssKAGy6t6vTZVEnyjJ7XS8nUp=NwZF6U-ZBQw@mail.gmail.com>
 <20161007232734.53d4dc89@anarchist>
Message-ID: <CADiSq7eNutK=ebR6pWqJ0RjWCaEysJr-RFigEGk423YFa-dU8g@mail.gmail.com>

On 8 October 2016 at 13:27, Barry Warsaw <barry at python.org> wrote:
> On Oct 07, 2016, at 11:31 PM, Maciej Szulik wrote:
>
>>There's one nit with that cherry-pick, it already creates the commit, and
>>current description states you should create a commit after running tests
>>[1].
>
> You can also use cherry-pick -n/--no-commit.

It probably makes more sense to assume a successful backport as the
default case, and cover "git commit --amend" to handle the case where
the tests fail - the ease with which history can be rewritten prior to
publication is the main UX benefit git offers over hg, so we may as
well take advantage of it.

That is, there are 3 reasonably common possible flows:

- backport with no merge conflicts, tests pass (default flow)
- backport with merge conflicts (git will prompt for this)
- backport with test failures (cover with "git commit --amend")

Recommending "--no-commit" as the default makes the first flow longer
by adding a separate commit step without actually simplifying the
others.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From barry at python.org  Sun Oct  9 08:20:24 2016
From: barry at python.org (Barry Warsaw)
Date: Sun, 9 Oct 2016 08:20:24 -0400
Subject: [core-workflow] instructions for cherrypicking a change from
 master
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
 <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
 <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>
 <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>
 <CALC2N4ZEWuewVssKAGy6t6vTZVEnyjJ7XS8nUp=NwZF6U-ZBQw@mail.gmail.com>
 <20161007232734.53d4dc89@anarchist>
 <CADiSq7eNutK=ebR6pWqJ0RjWCaEysJr-RFigEGk423YFa-dU8g@mail.gmail.com>
Message-ID: <20161009082024.3a09887d@anarchist>

On Oct 09, 2016, at 12:43 PM, Nick Coghlan wrote:

>It probably makes more sense to assume a successful backport as the
>default case

We'll have to see.  Maybe Python's code won't change so much between major
versions, but I've been on projects where refactorings and other changes do
result in most cherry picks needing massage.

>, and cover "git commit --amend" to handle the case where the tests fail -
>the ease with which history can be rewritten prior to publication is the main
>UX benefit git offers over hg, so we may as well take advantage of it.

Yeah; I have a visceral reaction to history modification, but git does seem to
be more amenable to that.  I can't check now, but what's the failure mode if
you --amend a pushed commit?  IIRC, the --amend succeeds but you'll get an
error on push, which IMO is later than it should be (i.e. git probably should
disallow --amend on published commits).

>That is, there are 3 reasonably common possible flows:
>
>- backport with no merge conflicts, tests pass (default flow)
>- backport with merge conflicts (git will prompt for this)
>- backport with test failures (cover with "git commit --amend")
>
>Recommending "--no-commit" as the default makes the first flow longer
>by adding a separate commit step without actually simplifying the
>others.

That's true, but I generally always want to review what git does before I
publish it, and not committing makes that easier for me.

The other thing is that there are lots of ways to accomplish things in git,
and everyone will have their favorite workflow.  That's totally fine as long
as things stay local.  It's okay to be opinionated and document the expected
common good path, but most important is to document anything that will have
global effects, because that affects everyone.   Maybe think about using words
like MUST and SHOULD to delineate the difference (a la RFCs).

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161009/0ca1bafc/attachment.sig>

From rosuav at gmail.com  Sun Oct  9 11:12:45 2016
From: rosuav at gmail.com (Chris Angelico)
Date: Mon, 10 Oct 2016 02:12:45 +1100
Subject: [core-workflow] instructions for cherrypicking a change from
 master
In-Reply-To: <20161009082024.3a09887d@anarchist>
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
 <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
 <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>
 <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>
 <CALC2N4ZEWuewVssKAGy6t6vTZVEnyjJ7XS8nUp=NwZF6U-ZBQw@mail.gmail.com>
 <20161007232734.53d4dc89@anarchist>
 <CADiSq7eNutK=ebR6pWqJ0RjWCaEysJr-RFigEGk423YFa-dU8g@mail.gmail.com>
 <20161009082024.3a09887d@anarchist>
Message-ID: <CAPTjJmpmQe3auFGS9JoF=2PySsNuAGKT+F93LEVgZ=92vBRjtg@mail.gmail.com>

On Sun, Oct 9, 2016 at 11:20 PM, Barry Warsaw <barry at python.org> wrote:
> On Oct 09, 2016, at 12:43 PM, Nick Coghlan wrote:
>
>>It probably makes more sense to assume a successful backport as the
>>default case
>
> We'll have to see.  Maybe Python's code won't change so much between major
> versions, but I've been on projects where refactorings and other changes do
> result in most cherry picks needing massage.

In my experience, CPython is stable enough that you can sometimes even
pick up a patch from *2.7* and apply it to the latest 3.x. (The
downside of this is that some files are oddly named, eg longobject.c,
which implements what we now call "int".) Between 3.5 and 3.6 it'll be
even more common for a patch to apply cleanly, and shortly after a
branch is cut (eg current 3.6 -> 3.7), near-certain.

And of the possible failure modes, "patch doesn't apply" is far more
likely than "patch applies but tests fail". In the former case, git
will tell you straight away; it's only in the latter case that you'll
need to amend the commit.

>>, and cover "git commit --amend" to handle the case where the tests fail -
>>the ease with which history can be rewritten prior to publication is the main
>>UX benefit git offers over hg, so we may as well take advantage of it.
>
> Yeah; I have a visceral reaction to history modification, but git does seem to
> be more amenable to that.  I can't check now, but what's the failure mode if
> you --amend a pushed commit?  IIRC, the --amend succeeds but you'll get an
> error on push, which IMO is later than it should be (i.e. git probably should
> disallow --amend on published commits).

It's pretty simple:

rosuav at sikorsky:~/Gypsum$ git push
To github.com:Rosuav/Gypsum
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'git at github.com:Rosuav/Gypsum'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

(And attempting a 'git pull' will highlight the fact that you've
edited history.)

The server will want to be configured to utterly reject
"non-fast-forward pushes"; git actually does allow you to override the
above message ("git push --force-with-lease" and friends), but
ultimately, it's the central server that chooses to accept or reject
the push. It's possible, for instance, to accept a force-push on a
topic branch but reject them on your primary branches, which would
allow people to rebase their "proposed change" branches freely (eg to
update them to the current codebase) without permitting any damage to
the version branches "3.5", "3.6", "master", etc. In GitHub terms,
this is done by protecting a branch:

https://help.github.com/articles/about-protected-branches/

In a more directly-managed environment, this would be implemented with
a pre-receive or update hook:

https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

As this is a simple script, it has all the flexibility of code, so any
rule can be implemented.

>>Recommending "--no-commit" as the default makes the first flow longer
>>by adding a separate commit step without actually simplifying the
>>others.
>
> That's true, but I generally always want to review what git does before I
> publish it, and not committing makes that easier for me.
>
> The other thing is that there are lots of ways to accomplish things in git,
> and everyone will have their favorite workflow.  That's totally fine as long
> as things stay local.  It's okay to be opinionated and document the expected
> common good path, but most important is to document anything that will have
> global effects, because that affects everyone.   Maybe think about using words
> like MUST and SHOULD to delineate the difference (a la RFCs).

That would be a personal workflow choice, then. +1 on RFC 2119 MUST vs
SHOULD usage. IMO the document should specify *one* recommended
workflow, because otherwise it's just way too confusing to read; and
then by its language, it can clarify which parts you're allowed to
diverge from and which not.

Most of git _does_ stay local, and to the greatest extent possible,
the server should be set up to accept or reject commits that don't
comply with the workflow's MUSTs. If that central server is under
python.org's direct control, that simply means codifying all the MUSTs
into the pre-receive/update hook (see above), the code for which can
then be published alongside the workflow documents as a sort of
"clarifying document".

ChrisA

From ncoghlan at gmail.com  Mon Oct 10 07:34:20 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 10 Oct 2016 21:34:20 +1000
Subject: [core-workflow] instructions for cherrypicking a change from
 master
In-Reply-To: <CAPTjJmpmQe3auFGS9JoF=2PySsNuAGKT+F93LEVgZ=92vBRjtg@mail.gmail.com>
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
 <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
 <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>
 <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>
 <CALC2N4ZEWuewVssKAGy6t6vTZVEnyjJ7XS8nUp=NwZF6U-ZBQw@mail.gmail.com>
 <20161007232734.53d4dc89@anarchist>
 <CADiSq7eNutK=ebR6pWqJ0RjWCaEysJr-RFigEGk423YFa-dU8g@mail.gmail.com>
 <20161009082024.3a09887d@anarchist>
 <CAPTjJmpmQe3auFGS9JoF=2PySsNuAGKT+F93LEVgZ=92vBRjtg@mail.gmail.com>
Message-ID: <CADiSq7cS4EstfLW5+J5jCFWxpC2EEQ5JZqhFPvxYe7Lj8JiHKg@mail.gmail.com>

On 10 October 2016 at 01:12, Chris Angelico <rosuav at gmail.com> wrote:
> In my experience, CPython is stable enough that you can sometimes even
> pick up a patch from *2.7* and apply it to the latest 3.x. (The
> downside of this is that some files are oddly named, eg longobject.c,
> which implements what we now call "int".) Between 3.5 and 3.6 it'll be
> even more common for a patch to apply cleanly, and shortly after a
> branch is cut (eg current 3.6 -> 3.7), near-certain.

Right, it's mainly when you collide with a refactoring that things get
painful (e.g. the SSL/TLS rebase in Python 2.7 ran into that).

In general though, we shouldn't see any more problems with cherry
picks than we see with forward merges, and there Misc/NEWS is the only
consistent source of conflicts.

> The server will want to be configured to utterly reject
> "non-fast-forward pushes"; git actually does allow you to override the
> above message ("git push --force-with-lease" and friends), but
> ultimately, it's the central server that chooses to accept or reject
> the push. It's possible, for instance, to accept a force-push on a
> topic branch but reject them on your primary branches, which would
> allow people to rebase their "proposed change" branches freely (eg to
> update them to the current codebase) without permitting any damage to
> the version branches "3.5", "3.6", "master", etc. In GitHub terms,
> this is done by protecting a branch:
>
> https://help.github.com/articles/about-protected-branches/

The fork-and-send-a-PR model makes this relatively straightforward -
folks can rebase and otherwise edit their PR branches in their own
fork freely, and then the main repo can be set to "fast forward only".

>>>Recommending "--no-commit" as the default makes the first flow longer
>>>by adding a separate commit step without actually simplifying the
>>>others.
>>
>> That's true, but I generally always want to review what git does before I
>> publish it, and not committing makes that easier for me.

While the cryptic nature of the incantations counted against it in the
original head-to-head DVCS review, the relative simplicity of
combining "git diff HEAD^" & "git commit --amend" has meant I've been
markedly less averse to eager commits in git than I am in Mercurial.

> That would be a personal workflow choice, then. +1 on RFC 2119 MUST vs
> SHOULD usage. IMO the document should specify *one* recommended
> workflow, because otherwise it's just way too confusing to read; and
> then by its language, it can clarify which parts you're allowed to
> diverge from and which not.

A lot of the SHOULDs will be "Use the web-based workflow to review and
merge changes, since that offloads more of the work to automated
systems and can be done from any client device".

While there will be cases where local client usage is needed (and
generating a backport PR will be one of them, unless/until GitHub
copies GitLab's cherry-pick-in-the-web-UI feature), allowing reviews
to be done that way is mainly for the benefit of current core devs
that prefer to do their reviews locally.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From rosuav at gmail.com  Mon Oct 10 09:58:15 2016
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 11 Oct 2016 00:58:15 +1100
Subject: [core-workflow] instructions for cherrypicking a change from
 master
In-Reply-To: <CADiSq7cS4EstfLW5+J5jCFWxpC2EEQ5JZqhFPvxYe7Lj8JiHKg@mail.gmail.com>
References: <CAP1=2W5FoON6r4ZMM-3z+_7VNGK++6TjnuRCAZ-7fFLu+1+aPA@mail.gmail.com>
 <CAPTjJmpLKVTKbx7TTScXOG-X9dCV6XBD5UuicVHs5GbBs_aFLw@mail.gmail.com>
 <CADiSq7fGjmrfoutFacx=f6erhziGBVvdk0V6KAXpck0HXd2wnA@mail.gmail.com>
 <CAPTjJmoxpVRfVdZdF2UsuJUPL732go1YpKzWeOU0-OBuKJn6PQ@mail.gmail.com>
 <CALC2N4ZEWuewVssKAGy6t6vTZVEnyjJ7XS8nUp=NwZF6U-ZBQw@mail.gmail.com>
 <20161007232734.53d4dc89@anarchist>
 <CADiSq7eNutK=ebR6pWqJ0RjWCaEysJr-RFigEGk423YFa-dU8g@mail.gmail.com>
 <20161009082024.3a09887d@anarchist>
 <CAPTjJmpmQe3auFGS9JoF=2PySsNuAGKT+F93LEVgZ=92vBRjtg@mail.gmail.com>
 <CADiSq7cS4EstfLW5+J5jCFWxpC2EEQ5JZqhFPvxYe7Lj8JiHKg@mail.gmail.com>
Message-ID: <CAPTjJmq6v3tHx_x-PKadYMHA0G5C8dxGUA4D4MiseAEcrd2QYg@mail.gmail.com>

On Mon, Oct 10, 2016 at 10:34 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 10 October 2016 at 01:12, Chris Angelico <rosuav at gmail.com> wrote:
>> In my experience, CPython is stable enough that you can sometimes even
>> pick up a patch from *2.7* and apply it to the latest 3.x. (The
>> downside of this is that some files are oddly named, eg longobject.c,
>> which implements what we now call "int".) Between 3.5 and 3.6 it'll be
>> even more common for a patch to apply cleanly, and shortly after a
>> branch is cut (eg current 3.6 -> 3.7), near-certain.
>
> Right, it's mainly when you collide with a refactoring that things get
> painful (e.g. the SSL/TLS rebase in Python 2.7 ran into that).

Makes sense. So it would probably be worth cherry-picking a patch one
branch at a time; I would expect that such code changes, once done,
are reflected in all future branches, so you'd have something like
"3.3-3.4 work this way, and 3.5-3.7 work that way". Should be pretty
obvious once people get started on it.

> In general though, we shouldn't see any more problems with cherry
> picks than we see with forward merges, and there Misc/NEWS is the only
> consistent source of conflicts.

Is Misc/NEWS needed for old branches? If not, the easiest way might be
to simply build the patch without NEWS, then cherry-pick it to all
other branches, and finally add NEWS to the latest branch only.

>> That would be a personal workflow choice, then. +1 on RFC 2119 MUST vs
>> SHOULD usage. IMO the document should specify *one* recommended
>> workflow, because otherwise it's just way too confusing to read; and
>> then by its language, it can clarify which parts you're allowed to
>> diverge from and which not.
>
> A lot of the SHOULDs will be "Use the web-based workflow to review and
> merge changes, since that offloads more of the work to automated
> systems and can be done from any client device".
>
> While there will be cases where local client usage is needed (and
> generating a backport PR will be one of them, unless/until GitHub
> copies GitLab's cherry-pick-in-the-web-UI feature), allowing reviews
> to be done that way is mainly for the benefit of current core devs
> that prefer to do their reviews locally.

Sounds good to me. Those who are comfortable with local tools are
welcome to use them; if you've become as familiar with gitk as I have,
you won't want to give it up. (hgk/'hg view' is a poor clone of gitk,
with a fraction of its power. Don't judge gitk by hgk!) The default
workflow will be the nice simple web-based one, but there are plenty
of equivalents. GitHub will notice that you've pushed all the commits
in a PR and automatically mark it as "Merged", for instance, so you
don't have to worry about going and doing some bookkeeping.

ChrisA