From brett at python.org  Fri Mar  4 15:54:24 2016
From: brett at python.org (Brett Cannon)
Date: Fri, 04 Mar 2016 20:54:24 +0000
Subject: [core-workflow] GitHub migration update
Message-ID: <CAP1=2W4LS2XevB7NSpKCdUE4fjc7+C7mFXsHBiaUJqTm30CXrA@mail.gmail.com>

Just a quick update so people know what's going on.

First, thanks to Maciej Szulik for stepping up to help with bugs.python.org
changes! There are now patches to add a GitHub field for user accounts and
adding an endpoint for that data at
http://psf.upfronthosting.co.za/roundup/meta/issue579 and
http://psf.upfronthosting.co.za/roundup/meta/issue581, respectively. Ezio
has told me he is busy ATM but is hoping to help get this stuff in the
middle of this month (although I'm sure patch reviews are always welcome).

Two, Senthil is still tracking the git -> hg migration tool choices at
https://github.com/orsenthil/cpython-hg-to-git . Since we're not migrating
yet there is no need to worry about getting an answer to this problem right
now. It sounds like hg-git might win out, in which case it might be worth
looking at what difference there may be between the ideal conversion and
what is already at https://github.com/python/cpython since if the output is
close enough it might be nicer to simply keep the current repo and not
break people's pre-existing checkouts.

Three, the CLA bot is coded sans the work required to integrate with the
future b.p.o endpoint: https://github.com/brettcannon/knights-who-say-ni.
At some point I will need a GitHub account for the bot and to get it hosted
on Heroku which is all stuff for infrastructure@ (which I'm handling). I
also need to move it over to the python org on GitHub instead of keeping it
under my personal account now that I have ownership privileges for the
 python org.

Because people keep asking me privately, my hoped-for timeline is to get
the non-cpython repositories moved over by PyCon US 2016. As for the
cpython repo itself, my hope is to be ready to switch after Python 3.6.0 is
released (which is slated for December of this year). It may be possible to
move the cpython repo sooner, but there are enough parts to that migration
that it might be hard to get everything together faster than that, plus I
will need to talk with the 3.6 release manager to see if they are even
willing to migrate during the alpha or beta cycles of 3.6. But I definitely
want to try and see this completed no later than a year from when I
announced the final decision to move (which was Jan 1 of this year).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160304/f3d5d3c6/attachment.html>

From ncoghlan at gmail.com  Sat Mar  5 21:27:52 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 6 Mar 2016 12:27:52 +1000
Subject: [core-workflow] Spelling out a suggested local workflow for sending
 PRs?
Message-ID: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>

Something that came up at work recently was instructing people on how best
to configure local git clones for working with a "fork+PR" development
model, where you have your own server-side fork for the project that you
then use to submit pull requests. The trick is that there's an easy way to
do this and a hard way, and it isn't immediately obvious which is which :)

The easy way:

* clone the upstream repo read-only
* add your fork as an additional read/write remote:
  * e.g. "git remote add pr <URL of fork>"
* work in a branch
  * e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue"
* publish via your fork, and then submit back to the main repo
  * "git push pr"
  * use the web UI to submit the PR

The hard way:

* clone your fork read/write
* still work in topic branches
* waste time keeping master in your fork up to date
* forget the previous step, and submit PRs against a stale version of master

I bring it up as when I first started using GitHub, the second way seemed
intuitively obvious to me, but it actually makes things harder than they
need to be.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160306/3c1778ee/attachment.html>

From rosuav at gmail.com  Sat Mar  5 21:42:54 2016
From: rosuav at gmail.com (Chris Angelico)
Date: Sun, 6 Mar 2016 13:42:54 +1100
Subject: [core-workflow] Spelling out a suggested local workflow for
 sending PRs?
In-Reply-To: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
References: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
Message-ID: <CAPTjJmrrRP05T3cYVd1d889bzeZxEg8GvH0-Y_nB8wMkUDBooQ@mail.gmail.com>

On Sun, Mar 6, 2016 at 1:27 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> The easy way:
>
> * clone the upstream repo read-only
> * add your fork as an additional read/write remote:
>   * e.g. "git remote add pr <URL of fork>"
> * work in a branch
>   * e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue"
> * publish via your fork, and then submit back to the main repo
>   * "git push pr"
>   * use the web UI to submit the PR
>

My workflow is exactly this, except that I have my own fork under the
name "origin", and the upstream as "upstream". I then tell have these
two commands (script/alias):

branch:
git fetch upstream master:master
git checkout -b "$1" master

push:
git push -u origin `git symbolic-ref --short HEAD`


To work on something:

$ branch issueNNNN-whatever-branch-name
... make edits ...
$ git commit ...
$ push

And then use the web UI to submit the PR. (There are alternatives to
that, but I don't do enough to justify them.)

The 'branch' command does a network transaction, so it'll take a bit
of time. But it's the easiest way to make sure I never forget to
update to the latest upstream. If in doubt, script it :)

ChrisA

From phd at phdru.name  Sun Mar  6 04:27:50 2016
From: phd at phdru.name (Oleg Broytman)
Date: Sun, 6 Mar 2016 10:27:50 +0100
Subject: [core-workflow] Spelling out a suggested local workflow for
 sending PRs?
In-Reply-To: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
References: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
Message-ID: <20160306092750.GA30070@phdru.name>

That should be added to the new devguide or a PEP.

On Sun, Mar 06, 2016 at 12:27:52PM +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Something that came up at work recently was instructing people on how best
> to configure local git clones for working with a "fork+PR" development
> model, where you have your own server-side fork for the project that you
> then use to submit pull requests. The trick is that there's an easy way to
> do this and a hard way, and it isn't immediately obvious which is which :)
> 
> The easy way:
> 
> * clone the upstream repo read-only
> * add your fork as an additional read/write remote:
>   * e.g. "git remote add pr <URL of fork>"
> * work in a branch
>   * e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue"
> * publish via your fork, and then submit back to the main repo
>   * "git push pr"
>   * use the web UI to submit the PR
> 
> The hard way:
> 
> * clone your fork read/write
> * still work in topic branches
> * waste time keeping master in your fork up to date
> * forget the previous step, and submit PRs against a stale version of master
> 
> I bring it up as when I first started using GitHub, the second way seemed
> intuitively obvious to me, but it actually makes things harder than they
> need to be.
> 
> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

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

From paul.hoffman at gmail.com  Sun Mar  6 10:23:45 2016
From: paul.hoffman at gmail.com (Paul Hoffman)
Date: Sun, 6 Mar 2016 07:23:45 -0800
Subject: [core-workflow] Spelling out a suggested local workflow for
 sending PRs?
In-Reply-To: <20160306092750.GA30070@phdru.name>
References: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
 <20160306092750.GA30070@phdru.name>
Message-ID: <CAPik8yay1SwuS=PVpzY4Az1RMEY7C=kJh9pDcJrO-GFXiazGEg@mail.gmail.com>

I suggest that this be added to the new devguide, not a PEP, because there
are many workflows that work for different people.

One category of workflow is "make a clone on GitHub for each suggested
patch, then nuke that clone and start over for the next patch". A different
category of workflow is "clone on GitHub, clone from there to my local
machine, and keep my local machine up-to-date with the origin so I can keep
putting in patches easily". And there are other workflows that are
supported by different small tooling.

FWIW, I still don't know which I prefer. We are having this issue in the
IETF, and it is clear that people don't all agree on what they prefer.

I'm happy to write text up on this for the devguide when it gets time to do
so.

--Paul Hoffman

On Sun, Mar 6, 2016 at 1:27 AM, Oleg Broytman <phd at phdru.name> wrote:

> That should be added to the new devguide or a PEP.
>
> On Sun, Mar 06, 2016 at 12:27:52PM +1000, Nick Coghlan <ncoghlan at gmail.com>
> wrote:
> > Something that came up at work recently was instructing people on how
> best
> > to configure local git clones for working with a "fork+PR" development
> > model, where you have your own server-side fork for the project that you
> > then use to submit pull requests. The trick is that there's an easy way
> to
> > do this and a hard way, and it isn't immediately obvious which is which
> :)
> >
> > The easy way:
> >
> > * clone the upstream repo read-only
> > * add your fork as an additional read/write remote:
> >   * e.g. "git remote add pr <URL of fork>"
> > * work in a branch
> >   * e.g. "git checkout master && git checkout -b
> issueNNNN-summary-of-issue"
> > * publish via your fork, and then submit back to the main repo
> >   * "git push pr"
> >   * use the web UI to submit the PR
> >
> > The hard way:
> >
> > * clone your fork read/write
> > * still work in topic branches
> > * waste time keeping master in your fork up to date
> > * forget the previous step, and submit PRs against a stale version of
> master
> >
> > I bring it up as when I first started using GitHub, the second way seemed
> > intuitively obvious to me, but it actually makes things harder than they
> > need to be.
> >
> > Cheers,
> > Nick.
> >
> > --
> > Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
> 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/20160306/d460f88e/attachment-0001.html>

From doug at doughellmann.com  Sun Mar  6 15:28:45 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Sun, 6 Mar 2016 15:28:45 -0500
Subject: [core-workflow] the Misc/NEWS problem
In-Reply-To: <1457279814-sup-5824@lrrr.local>
References: <CAP1=2W49QHKHfB2DQdnKXNu+Fy7i9yqegMQof7HeCB9s0rLOBA@mail.gmail.com>
 <55C33014.40708@egenix.com>
 <CADiSq7fNikAsUWZy6vMykbnzvin6KCEPqyto6fzohwJdZJ9FKg@mail.gmail.com>
 <CAP1=2W7mo=XEEKccPyjcj6GdBc1n1DHQkUS1ryufL3EQgZnRow@mail.gmail.com>
 <20150806194604.D704D250FDE@webabinitio.net>
 <CADiSq7cxPSzqbg1jR=YkSjR5oyKLASjjA6q5ttCuqeFuRc+pyg@mail.gmail.com>
 <CAP1=2W6RxTv+A5epYz8s8XCWTPTuPbJW+EE=BJ=GF-3PRO2NpA@mail.gmail.com>
 <CADiSq7caQivvyjQbDip9Nu9Q6YHYWAq9P5eeAkt773HDdVKqsA@mail.gmail.com>
 <CAP1=2W7ZwXogBwS5iTuP3r=TFgGGqynq--=Y5gguyPkPzrh47w@mail.gmail.com>
 <20150808201755.8198A250FB5@webabinitio.net>
 <CAP1=2W7ERNLQvDgv-hwaYNvmpQVW0AzoPHxiVMMz6K1swNTA4w@mail.gmail.com>
 <CAP1=2W5Ua29087HU69Gfa=2nubD8t-cmcoE05c=+0bZUzPFgDQ@mail.gmail.com>
 <CAP1=2W6wHhJh-SbMED44dLff3UcmU6Xes+S_Za7WUppKZhdwAw@mail.gmail.com>
 <1457279814-sup-5824@lrrr.local>
Message-ID: <5E0CB1E7-C3F9-4F15-A9ED-3D1FDFD93F97@doughellmann.com>

[I replied just to Brett, not the list.]

> On Mar 6, 2016, at 11:02 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> 
> Excerpts from bcannon's message of 2015-09-07 01:03:18 +0000:
>> I forgot to follow up here that there was nary a peep from
>> python-committers about the proposal of keeping NEWS entries in the issue
>> tracker, so we have a green light to implement this idea.
> 
> Sorry for following up on this so late; I'm just catching up on the
> archives and project status.
> 
> You might be interested in a tool called "reno" that we built for
> managing OpenStack release notes. Contributors place YAML files
> containing release notes in the source tree, and reno uses the git
> branch and tag history to determine which version those notes belong
> to and to build the set of notes to be displayed. There's a command
> line app to dump a simple RST file and Sphinx integration module
> to make it easy to integrate the published release notes along with
> other documentation. Because notes are part of the git history, it's
> easy to include them with patches copied into multiple branches for
> backporting fixes. Because notes are in files, instead of commit
> messages, it is possible to change the note after the fact. And because
> they're in files they go with the source.
> 
> More info on reno (including design considerations) is available
> at http://docs.openstack.org/developer/reno/ and some published
> release notes for the Nova project are available at
> http://docs.openstack.org/releasenotes/nova/.
> 
> If you're interested, I'm happy to answer questions here, now that
> I'm subscribed to the list.
> 
> Doug
> 
>> 
>> On Mon, Aug 10, 2015, 15:39 Brett Cannon <bcannon at gmail.com> wrote:
>> 
>>> I have told python-committers of our plan to make sure it won't lead to a
>>> revolt.
>>> 
>>> On Sat, 8 Aug 2015 at 14:25 Brett Cannon <bcannon at gmail.com> wrote:
>>> 
>>>> On Sat, Aug 8, 2015 at 1:18 PM R. David Murray <rdmurray at bitdance.com>
>>>> wrote:
>>>> 
>>>>> On Sat, 08 Aug 2015 17:44:04 -0000, Brett Cannon <bcannon at gmail.com>
>>>>> wrote:
>>>>>> OK, assuming David's in agreement then I think this approach wins with
>>>>> the
>>>>>> comma-separated field for commits that the hg hook for Roundup
>>>>> auto-appends
>>>>>> to and of course the field to enter the NEWS entry.
>>>>>> 
>>>>>> Now the next question is how easy/hard is it to implement this, how
>>>>> long
>>>>>> will it take, and who is willing to do the work? With this in hand we
>>>>> can
>>>>>> propose it to python-committers for 3.6 since the NEWS file should be
>>>>> easy
>>>>>> enough to back-fill to this approach while its still small.
>>>>> 
>>>>> Yes I agree this is the best approach, assuming we can get it
>>>>> implemented.  The advantage of #4, though, is that Ezio already did the
>>>>> work.
>>>>> 
>>>>> I'm *willing* to do the roundup work, but I don't know as I have the
>>>>> required time, at least for the next month.  Part of the trick is the
>>>>> need to get a test instance set up...there was work done at PyCon and
>>>>> after at making a tracker-in-a-box, so I'd need to find out where that
>>>>> was at and learn how to use it (or finish it, if needed).  The code
>>>>> itself is probably a half-day job, probably including enhancing the hook
>>>>> to update the commits field.  But together with getting a working test
>>>>> instance we're talking a couple days work at least.
>>>>> 
>>>> 
>>>> Perk of getting the tracker-in-a-box working is it's a one-time cost that
>>>> will be beneficial long term.
>>>> 
>>>> I also don't think there is a rush since we still have to convince
>>>> python-committers that this is the right solution. I plan to propose it on
>>>> Monday to the list to make sure we have buy-in.
>>>> 
>>>> 
>>>>> Writing the NEWS generating script is a not exactly trivial job, but
>>>>> probably wants to wait until we have the REST API.  So we'd have
>>>>> upgrading our Roundup to that when it lands on the list as well, with a
>>>>> 3.6 Beta 1 deadline on getting it all done.
>>>>> 
>>>> 
>>>> Yeah, so we have a bit of time to worry about the generation script.
>>>> 
>>> 
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150907/d59baee3/attachment-0001.html>


From ncoghlan at gmail.com  Mon Mar  7 04:13:05 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Mar 2016 19:13:05 +1000
Subject: [core-workflow] Spelling out a suggested local workflow for
 sending PRs?
In-Reply-To: <CAPik8yay1SwuS=PVpzY4Az1RMEY7C=kJh9pDcJrO-GFXiazGEg@mail.gmail.com>
References: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
 <20160306092750.GA30070@phdru.name>
 <CAPik8yay1SwuS=PVpzY4Az1RMEY7C=kJh9pDcJrO-GFXiazGEg@mail.gmail.com>
Message-ID: <CADiSq7d_D723w8ZBFFjgSMi5Of+_wjGvA19nkCcn1NgNrYW1VQ@mail.gmail.com>

On 7 March 2016 at 01:23, Paul Hoffman <paul.hoffman at gmail.com> wrote:
> I suggest that this be added to the new devguide, not a PEP, because there
> are many workflows that work for different people.
>
> One category of workflow is "make a clone on GitHub for each suggested
> patch, then nuke that clone and start over for the next patch". A different
> category of workflow is "clone on GitHub, clone from there to my local
> machine, and keep my local machine up-to-date with the origin so I can keep
> putting in patches easily".

The audience here is folks that don't already have a preferred
workflow for interesting with GitHub repos, so it's mainly that second
one I want to advise people against using - having used it myself as
my primary approach for working with GitHub repos until recently, I've
found it to be a recipe for submitting PRs against a stale checkout of
master, which then need to be rebased before they can be properly
reviewed. That's a pain for both submitters and reviewers, but it's
not obvious the problem exists until you've been using the approach
for a while.

The "ephemeral clone" approach is certainly an available option, but
it's significantly more work for each patch than a persistent clone,
and also doesn't tolerate having multiple PRs in flight at once, so
I'm less worried about people choosing it naively without realising
the additional hassle it causes.

Cheers,
Nick.

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

From ncoghlan at gmail.com  Mon Mar  7 04:13:44 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 7 Mar 2016 19:13:44 +1000
Subject: [core-workflow] Spelling out a suggested local workflow for
 sending PRs?
In-Reply-To: <CADiSq7d_D723w8ZBFFjgSMi5Of+_wjGvA19nkCcn1NgNrYW1VQ@mail.gmail.com>
References: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
 <20160306092750.GA30070@phdru.name>
 <CAPik8yay1SwuS=PVpzY4Az1RMEY7C=kJh9pDcJrO-GFXiazGEg@mail.gmail.com>
 <CADiSq7d_D723w8ZBFFjgSMi5Of+_wjGvA19nkCcn1NgNrYW1VQ@mail.gmail.com>
Message-ID: <CADiSq7c=3KLcOoz_6My4C5MRmdLSE64taMiUown4kpYRrRm1xA@mail.gmail.com>

On 7 March 2016 at 19:13, Nick Coghlan <ncoghlan at gmail.com> wrote:
> The audience here is folks that don't already have a preferred
> workflow for interesting with GitHub repos,

s/interesting/interacting/ :)

Cheers,
Nick.


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

From barry at python.org  Mon Mar  7 12:23:27 2016
From: barry at python.org (Barry Warsaw)
Date: Mon, 7 Mar 2016 12:23:27 -0500
Subject: [core-workflow] Spelling out a suggested local workflow for
 sending PRs?
References: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
Message-ID: <20160307122327.36d8a876@anarchist.wooz.org>

On Mar 06, 2016, at 12:27 PM, Nick Coghlan wrote:

>The easy way:
>
>* clone the upstream repo read-only
>* add your fork as an additional read/write remote:
>  * e.g. "git remote add pr <URL of fork>"
>* work in a branch
>  * e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue"
>* publish via your fork, and then submit back to the main repo
>  * "git push pr"
>  * use the web UI to submit the PR

This is essentially what I do too, but with some differences in names.  Chris
mentioned naming the 'upstream' remote to point to the upstream repo, and
'origin' to name his clone.  I do something different, but as a general
recommendation to people who are coming to this workflow previously unscathed
<wink> I like Chris's suggestion.

I generally only name my issue branches after the issue number,
e.g. "issue1234" since I can always go to the tracker to find details, and
these shouldn't be long-lived branches anyway.  I'd likely name a big feature
branch differently.

I think the essential bit of Nick's "easy way" is that you pretty much ignore
your fork's master.  It's just too much work to try to keep it sync'd against
upstream master.  Just do a pull of upstream master when you're starting
something new, and push your branches to your own fork (and many people won't
be able to push to upstream's repo anyway).  Then use the web ui to create a
pull request from that.

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

From rosuav at gmail.com  Mon Mar  7 12:35:31 2016
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 8 Mar 2016 04:35:31 +1100
Subject: [core-workflow] Spelling out a suggested local workflow for
 sending PRs?
In-Reply-To: <20160307122327.36d8a876@anarchist.wooz.org>
References: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
 <20160307122327.36d8a876@anarchist.wooz.org>
Message-ID: <CAPTjJmqF1DCqbb_GyGf_yXyZDTGb4aFkm4tCeKGNzag0uYSo_w@mail.gmail.com>

On Tue, Mar 8, 2016 at 4:23 AM, Barry Warsaw <barry at python.org> wrote:
> I think the essential bit of Nick's "easy way" is that you pretty much ignore
> your fork's master.  It's just too much work to try to keep it sync'd against
> upstream master.  Just do a pull of upstream master when you're starting
> something new, and push your branches to your own fork (and many people won't
> be able to push to upstream's repo anyway).  Then use the web ui to create a
> pull request from that.

Yes, exactly. And you can tell git that (in .git/config or using the
'git config' command); effectively, if you "git checkout master; git
pull", it'll pull in from upstream, not from origin (despite every
other branch being tied to origin). Very handy.

ChrisA

From brett at python.org  Mon Mar  7 12:36:46 2016
From: brett at python.org (Brett Cannon)
Date: Mon, 07 Mar 2016 17:36:46 +0000
Subject: [core-workflow] Spelling out a suggested local workflow for
 sending PRs?
In-Reply-To: <20160307122327.36d8a876@anarchist.wooz.org>
References: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
 <20160307122327.36d8a876@anarchist.wooz.org>
Message-ID: <CAP1=2W5Tea1xgLMqyHjdaDa-ctW9zqK4jM_K57QK05a5P8SGTg@mail.gmail.com>

On Mon, 7 Mar 2016 at 09:23 Barry Warsaw <barry at python.org> wrote:

> On Mar 06, 2016, at 12:27 PM, Nick Coghlan wrote:
>
> >The easy way:
> >
> >* clone the upstream repo read-only
> >* add your fork as an additional read/write remote:
> >  * e.g. "git remote add pr <URL of fork>"
> >* work in a branch
> >  * e.g. "git checkout master && git checkout -b
> issueNNNN-summary-of-issue"
> >* publish via your fork, and then submit back to the main repo
> >  * "git push pr"
> >  * use the web UI to submit the PR
>
> This is essentially what I do too, but with some differences in names.
> Chris
> mentioned naming the 'upstream' remote to point to the upstream repo, and
> 'origin' to name his clone.  I do something different, but as a general
> recommendation to people who are coming to this workflow previously
> unscathed
> <wink> I like Chris's suggestion.
>
> I generally only name my issue branches after the issue number,
> e.g. "issue1234" since I can always go to the tracker to find details, and
> these shouldn't be long-lived branches anyway.  I'd likely name a big
> feature
> branch differently.
>
> I think the essential bit of Nick's "easy way" is that you pretty much
> ignore
> your fork's master.  It's just too much work to try to keep it sync'd
> against
> upstream master.


And honestly, who's going to care about your copy of `master`? :) If anyone
works off your clone it's going to be for one of your branches, not
`master`.


>   Just do a pull of upstream master when you're starting
> something new, and push your branches to your own fork (and many people
> won't
> be able to push to upstream's repo anyway).  Then use the web ui to create
> a
> pull request from that.
>

And I think the other key is using "pr" as the remote's name so that you
don't want to throttle GitHub for having you type the name constantly. You
could do `git push --set-upstream pr` on the first push (or as soon as you
create the branch), but you would need to do 9 pushes to break even with
that many keystrokes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160307/cdf90bca/attachment.html>

From rosuav at gmail.com  Mon Mar  7 12:41:13 2016
From: rosuav at gmail.com (Chris Angelico)
Date: Tue, 8 Mar 2016 04:41:13 +1100
Subject: [core-workflow] Spelling out a suggested local workflow for
 sending PRs?
In-Reply-To: <CAP1=2W5Tea1xgLMqyHjdaDa-ctW9zqK4jM_K57QK05a5P8SGTg@mail.gmail.com>
References: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
 <20160307122327.36d8a876@anarchist.wooz.org>
 <CAP1=2W5Tea1xgLMqyHjdaDa-ctW9zqK4jM_K57QK05a5P8SGTg@mail.gmail.com>
Message-ID: <CAPTjJmpksRes-Ki27g-bPyyaBwsL6W8eH1a5OHg8wEOB921Y3w@mail.gmail.com>

On Tue, Mar 8, 2016 at 4:36 AM, Brett Cannon <brett at python.org> wrote:
>>   Just do a pull of upstream master when you're starting
>> something new, and push your branches to your own fork (and many people
>> won't
>> be able to push to upstream's repo anyway).  Then use the web ui to create
>> a
>> pull request from that.
>
>
> And I think the other key is using "pr" as the remote's name so that you
> don't want to throttle GitHub for having you type the name constantly. You
> could do `git push --set-upstream pr` on the first push (or as soon as you
> create the branch), but you would need to do 9 pushes to break even with
> that many keystrokes.
>

That's why I have my 'push' script. It's four keystrokes LESS than
'git push', and automatically sends a new branch to the appropriate
remote :)

ChrisA

From brett at python.org  Mon Mar  7 12:41:31 2016
From: brett at python.org (Brett Cannon)
Date: Mon, 07 Mar 2016 17:41:31 +0000
Subject: [core-workflow] Spelling out a suggested local workflow for
 sending PRs?
In-Reply-To: <CAPik8yay1SwuS=PVpzY4Az1RMEY7C=kJh9pDcJrO-GFXiazGEg@mail.gmail.com>
References: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
 <20160306092750.GA30070@phdru.name>
 <CAPik8yay1SwuS=PVpzY4Az1RMEY7C=kJh9pDcJrO-GFXiazGEg@mail.gmail.com>
Message-ID: <CAP1=2W4-Dv6wzzWfYnncScjT-W0bym1So+FQ4C0GzUPQoveV+Q@mail.gmail.com>

On Sun, 6 Mar 2016 at 07:24 Paul Hoffman <paul.hoffman at gmail.com> wrote:

> I suggest that this be added to the new devguide, not a PEP, because there
> are many workflows that work for different people.
>

Yep, this isn't policy but simply a suggestion, so it should go in the
devguide.


>
> One category of workflow is "make a clone on GitHub for each suggested
> patch, then nuke that clone and start over for the next patch". A different
> category of workflow is "clone on GitHub, clone from there to my local
> machine, and keep my local machine up-to-date with the origin so I can keep
> putting in patches easily". And there are other workflows that are
> supported by different small tooling.
>
> FWIW, I still don't know which I prefer. We are having this issue in the
> IETF, and it is clear that people don't all agree on what they prefer.
>
> I'm happy to write text up on this for the devguide when it gets time to
> do so.
>

Great! Thanks, Paul!

My hope is that we get the devguide moved over early so that we can create
a "github" branch to hold the GitHub-related changes so that as soon as
cpython is ready to switch it will take nothing more than a merge of the
branch into `master` to make the changes appear online.

-Brett


>
> --Paul Hoffman
>
> On Sun, Mar 6, 2016 at 1:27 AM, Oleg Broytman <phd at phdru.name> wrote:
>
>> That should be added to the new devguide or a PEP.
>>
>> On Sun, Mar 06, 2016 at 12:27:52PM +1000, Nick Coghlan <
>> ncoghlan at gmail.com> wrote:
>> > Something that came up at work recently was instructing people on how
>> best
>> > to configure local git clones for working with a "fork+PR" development
>> > model, where you have your own server-side fork for the project that you
>> > then use to submit pull requests. The trick is that there's an easy way
>> to
>> > do this and a hard way, and it isn't immediately obvious which is which
>> :)
>> >
>> > The easy way:
>> >
>> > * clone the upstream repo read-only
>> > * add your fork as an additional read/write remote:
>> >   * e.g. "git remote add pr <URL of fork>"
>> > * work in a branch
>> >   * e.g. "git checkout master && git checkout -b
>> issueNNNN-summary-of-issue"
>> > * publish via your fork, and then submit back to the main repo
>> >   * "git push pr"
>> >   * use the web UI to submit the PR
>> >
>> > The hard way:
>> >
>> > * clone your fork read/write
>> > * still work in topic branches
>> > * waste time keeping master in your fork up to date
>> > * forget the previous step, and submit PRs against a stale version of
>> master
>> >
>> > I bring it up as when I first started using GitHub, the second way
>> seemed
>> > intuitively obvious to me, but it actually makes things harder than they
>> > need to be.
>> >
>> > Cheers,
>> > Nick.
>> >
>> > --
>> > Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>
>> 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
>>
>
> _______________________________________________
> 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/20160307/68f9b46a/attachment-0001.html>

From ncoghlan at gmail.com  Mon Mar  7 17:36:46 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 8 Mar 2016 08:36:46 +1000
Subject: [core-workflow] Spelling out a suggested local workflow for
 sending PRs?
In-Reply-To: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
References: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
Message-ID: <CADiSq7d2ryy7__pXDV0OF998jD2TzahOK6smw7osJGruTokz2Q@mail.gmail.com>

On 6 Mar 2016 12:27, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
>
> Something that came up at work recently was instructing people on how
best to configure local git clones for working with a "fork+PR" development
model, where you have your own server-side fork for the project that you
then use to submit pull requests. The trick is that there's an easy way to
do this and a hard way, and it isn't immediately obvious which is which :)
>
> The easy way:
>

Oops, I left out the first step here:

* create a personal fork of the upstream repo on GitHub

> * clone the upstream repo read-only
> * add your fork as an additional read/write remote:
>   * e.g. "git remote add pr <URL of fork>"
> * work in a branch
>   * e.g. "git checkout master && git checkout -b
issueNNNN-summary-of-issue"
> * publish via your fork, and then submit back to the main repo
>   * "git push pr"
>   * use the web UI to submit the PR

The first step needs to be done once per project, and steps 2 & 3 once per
project per client device.

The actual patch development process is then a matter of ensuring your
clone is up to date, creating a working branch, making & committing the
changes, pushing to your personal fork, and then submitting the PR.

Regards,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160308/4ab0f62e/attachment.html>

From ncoghlan at gmail.com  Mon Mar  7 20:17:56 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 8 Mar 2016 11:17:56 +1000
Subject: [core-workflow] Spelling out a suggested local workflow for
 sending PRs?
In-Reply-To: <20160307122327.36d8a876@anarchist.wooz.org>
References: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
 <20160307122327.36d8a876@anarchist.wooz.org>
Message-ID: <CADiSq7eHuGRGd1exjDEdEHnO3qpFXEpgHp5o33YPqTdkAvLK=Q@mail.gmail.com>

On 8 Mar 2016 03:23, "Barry Warsaw" <barry at python.org> wrote:
> On Mar 06, 2016, at 12:27 PM, Nick Coghlan wrote:.
>
> I think the essential bit of Nick's "easy way" is that you pretty much
ignore
> your fork's master.  It's just too much work to try to keep it sync'd
against
> upstream master.

Exactly, although it's actually "Vit's easy way" (my colleague Vit Ondruch
proposed this as the recommended GitLab workflow for our current project at
work, and it finally clicked for me what I'd been doing wrong all this
time).

That said, Chris's variant of just setting the upstream of the local
clone's master branch to the upstream repo so "git checkout master && git
pull" on master reads directly from upstream, while "git push" defaults to
going to your fork, does sound intriguing - I'm going to try that on some
of my existing projects where I made the original clone from my personal
fork.

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160308/af855912/attachment.html>

From donald at stufft.io  Tue Mar  8 08:12:05 2016
From: donald at stufft.io (Donald Stufft)
Date: Tue, 8 Mar 2016 08:12:05 -0500
Subject: [core-workflow] Spelling out a suggested local workflow for
 sending PRs?
In-Reply-To: <CADiSq7eHuGRGd1exjDEdEHnO3qpFXEpgHp5o33YPqTdkAvLK=Q@mail.gmail.com>
References: <CADiSq7d7osoFB=g+oPCKLiQTuL7JzxaDwY32q1kyiEOSKESF6Q@mail.gmail.com>
 <20160307122327.36d8a876@anarchist.wooz.org>
 <CADiSq7eHuGRGd1exjDEdEHnO3qpFXEpgHp5o33YPqTdkAvLK=Q@mail.gmail.com>
Message-ID: <05C88751-06B5-401D-9540-B9C6926D9B63@stufft.io>


> On Mar 7, 2016, at 8:17 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> That said, Chris's variant of just setting the upstream of the local clone's master branch to the upstream repo so "git checkout master && git pull" on master reads directly from upstream, while "git push" defaults to going to your fork, does sound intriguing - I'm going to try that on some of my existing projects where I made the original clone from my personal fork.


This is what I do, it works very well in my experience.

I also add a fetch line so that pull requests show up with refs and I can check them out locally. For example, here is my .git/config from one of my repositories: https://bpaste.net/show/2fd5a8dfe33e <https://bpaste.net/show/2fd5a8dfe33e>

This means that my ``master`` branch tracks the upstream, the default origin is my fork, and I can checkout PRs locally using:

    $ git checkout pr/N # Checks out the PR as a branch tracking the PR
    $ git checkout -b whatever upstream/pr/N  # checkout out the PR as a a new branch based on the PR.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160308/aab9faaa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160308/aab9faaa/attachment.sig>

From phd at phdru.name  Thu Mar 17 05:48:44 2016
From: phd at phdru.name (Oleg Broytman)
Date: Thu, 17 Mar 2016 10:48:44 +0100
Subject: [core-workflow] GitHub Workflow
Message-ID: <20160317094844.GA23087@phdru.name>

An interesting example of GitHub Workflow (used by Frameworks team at BBC
News): http://www.integralist.co.uk/posts/github-workflow.html

The basis of their workflow is this:

-- Open a GitHub PR (Pull Request) by creating a new feature branch
   from master
-- Make feature specific changes and request a code review
-- If given a "thumbs up", this means the PR author is allowed to
   handle merging the PR
-- The merge process requires a set of sub steps (see below)

The steps (in summary) are:

-- Interactively rebase master onto the feature branch
-- Squash all feature commits into a single commit:
   -- (this isn't exactly a squash)
   -- the first line of the commit message should be the same as the
      GitHub PR title
-- As part of the rebase ensure:
   -- the author(s) is mentioned in the commit message
   -- the PR is mentioned (and any associated issues as well)
-- Move back to the master branch and cherry-pick in the newly squashed
   feature commit

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

From tseaver at palladion.com  Thu Mar 17 10:13:53 2016
From: tseaver at palladion.com (Tres Seaver)
Date: Thu, 17 Mar 2016 10:13:53 -0400
Subject: [core-workflow] GitHub Workflow
In-Reply-To: <20160317094844.GA23087@phdru.name>
References: <20160317094844.GA23087@phdru.name>
Message-ID: <ncee31$425$1@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/17/2016 05:48 AM, Oleg Broytman wrote:

> -- Interactively rebase master onto the feature branch

The directionality seems wrong here:  one would be rebasing the feature
branch onto the head of `master`:  "rebase master" would mean "rewrite
master's history", which cannot be correct.

> -- Move back to the master branch and cherry-pick in the newly
> squashed feature commit

I don't understand the cherry-pick:  why not just merge the rebased
feature branch with 'git merge --squash', and fix up the changelog in the
commit message of the merge commit?


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJW6rubAAoJEPKpaDSJE9HYeScP/3oG/duoBb4RFJz4vxuN1+Or
a/sqc2GK3mGWs2G4HpcCIJl2jdOqsT3zvB7//Mp2DbcCwaBnQB4wg8BqBZN7z+lO
Qw7zNOerJpMjaQarVIMCtGi/vPkpN8ZPbM9y5qwhjDfywxD62aV/+H7yAg2rw+PY
5HfstwDDTiDdHiaa7MUrKTuVO6X5h1p0ZITpaCLZuGYf9tL17Ly3vaoZOe7SNz2/
k9w6TT6hNiD0YYdiNYv5ettD9o4UjQbQThHUmV0dQ1umcn6+GAEEX3w8xh5ewMcH
MVC/Ptx32zDRqN411fguudJv2IzOB1m1nJnpQjG9KQ0ZSqNdYAgCj9fb9eRWue2M
TuDDHOX/RLlOXGBi/vtbzF1bldnUDRF3mlEmFosNvLbDGdhrGE+NKEqCTq9kylE6
QsqPeCbVaxjU3gc705hKGFm0Owqg0Kacc8HXIZXYY/aRNpGPEFYq+e1wlUOThFiE
f7rcFJOPBDhz9gsbhcUNwV/97MZ0dO9kqwKfcV9NVYNssk1aj/XZEnajMACdBQ4t
WJdCuiAeGefVSEKmxegM6GK7jI12auf95zG9NeqHPkyGhcnSknp7z9V2yAzmcjFt
ZohcrJKtLffPS8Fc2rFK8jaQjWCtmOMLBwPardq3eCtpHv35MS/W0FNRuL2f5MJX
LAJSqpbiJfEsv/uFSDDm
=952r
-----END PGP SIGNATURE-----


From phd at phdru.name  Thu Mar 17 13:17:47 2016
From: phd at phdru.name (Oleg Broytman)
Date: Thu, 17 Mar 2016 18:17:47 +0100
Subject: [core-workflow] GitHub Workflow
In-Reply-To: <ncee31$425$1@ger.gmane.org>
References: <20160317094844.GA23087@phdru.name>
 <ncee31$425$1@ger.gmane.org>
Message-ID: <20160317171747.GA13430@phdru.name>

On Thu, Mar 17, 2016 at 10:13:53AM -0400, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03/17/2016 05:48 AM, Oleg Broytman wrote:
> 
> > -- Interactively rebase master onto the feature branch
> 
> The directionality seems wrong here:  one would be rebasing the feature
> branch onto the head of `master`:  "rebase master" would mean "rewrite
> master's history", which cannot be correct.

   It seems they rebase non-pushed commits in master onto the feature
branch.

> > -- Move back to the master branch and cherry-pick in the newly
> > squashed feature commit
> 
> I don't understand the cherry-pick:  why not just merge the rebased
> feature branch with 'git merge --squash', and fix up the changelog in the
> commit message of the merge commit?

   That would require a lot of manual editing of the commit message
while interactive rebase and cherry-pick preserve messages.

> Tres.
> - -- 
> ===================================================================
> Tres Seaver          +1 540-429-0999          tseaver at palladion.com
> Palladion Software   "Excellence by Design"    http://palladion.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQIcBAEBAgAGBQJW6rubAAoJEPKpaDSJE9HYeScP/3oG/duoBb4RFJz4vxuN1+Or
> a/sqc2GK3mGWs2G4HpcCIJl2jdOqsT3zvB7//Mp2DbcCwaBnQB4wg8BqBZN7z+lO
> Qw7zNOerJpMjaQarVIMCtGi/vPkpN8ZPbM9y5qwhjDfywxD62aV/+H7yAg2rw+PY
> 5HfstwDDTiDdHiaa7MUrKTuVO6X5h1p0ZITpaCLZuGYf9tL17Ly3vaoZOe7SNz2/
> k9w6TT6hNiD0YYdiNYv5ettD9o4UjQbQThHUmV0dQ1umcn6+GAEEX3w8xh5ewMcH
> MVC/Ptx32zDRqN411fguudJv2IzOB1m1nJnpQjG9KQ0ZSqNdYAgCj9fb9eRWue2M
> TuDDHOX/RLlOXGBi/vtbzF1bldnUDRF3mlEmFosNvLbDGdhrGE+NKEqCTq9kylE6
> QsqPeCbVaxjU3gc705hKGFm0Owqg0Kacc8HXIZXYY/aRNpGPEFYq+e1wlUOThFiE
> f7rcFJOPBDhz9gsbhcUNwV/97MZ0dO9kqwKfcV9NVYNssk1aj/XZEnajMACdBQ4t
> WJdCuiAeGefVSEKmxegM6GK7jI12auf95zG9NeqHPkyGhcnSknp7z9V2yAzmcjFt
> ZohcrJKtLffPS8Fc2rFK8jaQjWCtmOMLBwPardq3eCtpHv35MS/W0FNRuL2f5MJX
> LAJSqpbiJfEsv/uFSDDm
> =952r
> -----END PGP SIGNATURE-----

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

From rosuav at gmail.com  Thu Mar 17 13:35:17 2016
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 18 Mar 2016 04:35:17 +1100
Subject: [core-workflow] GitHub Workflow
In-Reply-To: <20160317171747.GA13430@phdru.name>
References: <20160317094844.GA23087@phdru.name> <ncee31$425$1@ger.gmane.org>
 <20160317171747.GA13430@phdru.name>
Message-ID: <CAPTjJmoJDEnFLmzK05jy+tLcGjipzEGDqZD2ANJpxoyn8sABZQ@mail.gmail.com>

On Fri, Mar 18, 2016 at 4:17 AM, Oleg Broytman <phd at phdru.name> wrote:
>> I don't understand the cherry-pick:  why not just merge the rebased
>> feature branch with 'git merge --squash', and fix up the changelog in the
>> commit message of the merge commit?
>
>    That would require a lot of manual editing of the commit message
> while interactive rebase and cherry-pick preserve messages.

There are some definite oddities to the workflow. For instance, using
"reword" followed by "fixup" lets you edit the original commit's
message, but without any reference to the subsequent commits; in
contrast, using "squash" would have shown all the messages - and every
version of git that I've ever used has permitted a squashed commit's
message to be edited, so either that's super old or there's some other
reason for this.

Personally, I don't believe in squashing the commits of a PR/merge (I
see the sub-history as important, not just the history of "this
feature was merged in" - although for trivial changes, where there's
one simple commit and then a follow-up to fix a typo or something,
maybe it's tidier), but if that's what you want, I'd simply rebase the
feature branch to squash it (at the same time as rebasing it onto the
latest master), and then merge. Way WAY simpler.

ChrisA

From phd at phdru.name  Thu Mar 17 13:44:14 2016
From: phd at phdru.name (Oleg Broytman)
Date: Thu, 17 Mar 2016 18:44:14 +0100
Subject: [core-workflow] GitHub Workflow
In-Reply-To: <CAPTjJmoJDEnFLmzK05jy+tLcGjipzEGDqZD2ANJpxoyn8sABZQ@mail.gmail.com>
References: <20160317094844.GA23087@phdru.name> <ncee31$425$1@ger.gmane.org>
 <20160317171747.GA13430@phdru.name>
 <CAPTjJmoJDEnFLmzK05jy+tLcGjipzEGDqZD2ANJpxoyn8sABZQ@mail.gmail.com>
Message-ID: <20160317174414.GA22135@phdru.name>

On Fri, Mar 18, 2016 at 04:35:17AM +1100, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, Mar 18, 2016 at 4:17 AM, Oleg Broytman <phd at phdru.name> wrote:
> >> I don't understand the cherry-pick:  why not just merge the rebased
> >> feature branch with 'git merge --squash', and fix up the changelog in the
> >> commit message of the merge commit?
> >
> >    That would require a lot of manual editing of the commit message
> > while interactive rebase and cherry-pick preserve messages.
> 
> There are some definite oddities to the workflow. For instance, using
> "reword" followed by "fixup" lets you edit the original commit's
> message, but without any reference to the subsequent commits; in
> contrast, using "squash" would have shown all the messages - and every
> version of git that I've ever used has permitted a squashed commit's
> message to be edited, so either that's super old or there's some other
> reason for this.

   Fixup (during an interactive rebase) combines commit messages.

> Personally, I don't believe in squashing the commits of a PR/merge (I
> see the sub-history as important, not just the history of "this
> feature was merged in" - although for trivial changes, where there's
> one simple commit and then a follow-up to fix a typo or something,
> maybe it's tidier), but if that's what you want, I'd simply rebase the
> feature branch to squash it (at the same time as rebasing it onto the
> latest master), and then merge. Way WAY simpler.

   Me too. I have never used squashed merge. But "branchiful"
development has its own troubles like problems with bisect.

> ChrisA

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

From rosuav at gmail.com  Thu Mar 17 14:14:52 2016
From: rosuav at gmail.com (Chris Angelico)
Date: Fri, 18 Mar 2016 05:14:52 +1100
Subject: [core-workflow] GitHub Workflow
In-Reply-To: <20160317174414.GA22135@phdru.name>
References: <20160317094844.GA23087@phdru.name> <ncee31$425$1@ger.gmane.org>
 <20160317171747.GA13430@phdru.name>
 <CAPTjJmoJDEnFLmzK05jy+tLcGjipzEGDqZD2ANJpxoyn8sABZQ@mail.gmail.com>
 <20160317174414.GA22135@phdru.name>
Message-ID: <CAPTjJmqwSkZo0V07UWfw22ZvrHrt=qrptv5u1B9V45LV7Wy0Fw@mail.gmail.com>

On Fri, Mar 18, 2016 at 4:44 AM, Oleg Broytman <phd at phdru.name> wrote:
> On Fri, Mar 18, 2016 at 04:35:17AM +1100, Chris Angelico <rosuav at gmail.com> wrote:
>> On Fri, Mar 18, 2016 at 4:17 AM, Oleg Broytman <phd at phdru.name> wrote:
>> >> I don't understand the cherry-pick:  why not just merge the rebased
>> >> feature branch with 'git merge --squash', and fix up the changelog in the
>> >> commit message of the merge commit?
>> >
>> >    That would require a lot of manual editing of the commit message
>> > while interactive rebase and cherry-pick preserve messages.
>>
>> There are some definite oddities to the workflow. For instance, using
>> "reword" followed by "fixup" lets you edit the original commit's
>> message, but without any reference to the subsequent commits; in
>> contrast, using "squash" would have shown all the messages - and every
>> version of git that I've ever used has permitted a squashed commit's
>> message to be edited, so either that's super old or there's some other
>> reason for this.
>
>    Fixup (during an interactive rebase) combines commit messages.

Fixup discards the subsequent message(s); it's absolutely awesome for
the case where your initial message was perfect (eg when you're
patching in a typo fix or something), but for this workflow, they're
editing the message anyway.

>> Personally, I don't believe in squashing the commits of a PR/merge (I
>> see the sub-history as important, not just the history of "this
>> feature was merged in" - although for trivial changes, where there's
>> one simple commit and then a follow-up to fix a typo or something,
>> maybe it's tidier), but if that's what you want, I'd simply rebase the
>> feature branch to squash it (at the same time as rebasing it onto the
>> latest master), and then merge. Way WAY simpler.
>
>    Me too. I have never used squashed merge. But "branchiful"
> development has its own troubles like problems with bisect.

Yes, it does. Most of the time, you can just rebase the commits into a
linear history and run with it; since git retains separate Author and
Committer names and timestamps, you can give proper credit to the
contributor, while still ordering things appropriately. If you want to
retain the history of "this group of commits did one job" without
losing the commits themselves, you have to use merges. Otherwise, it's
one or the other.

One of the beauties of git is that it allows myriad workflows. One of
the great difficulties of getting started with git is that it allows
myriad workflows. The curse of choice, multiplied out. :)

ChrisA

From phd at phdru.name  Thu Mar 17 14:21:55 2016
From: phd at phdru.name (Oleg Broytman)
Date: Thu, 17 Mar 2016 19:21:55 +0100
Subject: [core-workflow] GitHub Workflow
In-Reply-To: <CAPTjJmqwSkZo0V07UWfw22ZvrHrt=qrptv5u1B9V45LV7Wy0Fw@mail.gmail.com>
References: <20160317094844.GA23087@phdru.name> <ncee31$425$1@ger.gmane.org>
 <20160317171747.GA13430@phdru.name>
 <CAPTjJmoJDEnFLmzK05jy+tLcGjipzEGDqZD2ANJpxoyn8sABZQ@mail.gmail.com>
 <20160317174414.GA22135@phdru.name>
 <CAPTjJmqwSkZo0V07UWfw22ZvrHrt=qrptv5u1B9V45LV7Wy0Fw@mail.gmail.com>
Message-ID: <20160317182155.GA27671@phdru.name>

On Fri, Mar 18, 2016 at 05:14:52AM +1100, Chris Angelico <rosuav at gmail.com> wrote:
> On Fri, Mar 18, 2016 at 4:44 AM, Oleg Broytman <phd at phdru.name> wrote:
> > On Fri, Mar 18, 2016 at 04:35:17AM +1100, Chris Angelico <rosuav at gmail.com> wrote:
> >> On Fri, Mar 18, 2016 at 4:17 AM, Oleg Broytman <phd at phdru.name> wrote:
> >> >> I don't understand the cherry-pick:  why not just merge the rebased
> >> >> feature branch with 'git merge --squash', and fix up the changelog in the
> >> >> commit message of the merge commit?
> >> >
> >> >    That would require a lot of manual editing of the commit message
> >> > while interactive rebase and cherry-pick preserve messages.
> >>
> >> There are some definite oddities to the workflow. For instance, using
> >> "reword" followed by "fixup" lets you edit the original commit's
> >> message, but without any reference to the subsequent commits; in
> >> contrast, using "squash" would have shown all the messages - and every
> >> version of git that I've ever used has permitted a squashed commit's
> >> message to be edited, so either that's super old or there's some other
> >> reason for this.
> >
> >    Fixup (during an interactive rebase) combines commit messages.
> 
> Fixup discards the subsequent message(s); it's absolutely awesome for
> the case where your initial message was perfect (eg when you're
> patching in a typo fix or something), but for this workflow, they're
> editing the message anyway.

   Ah, yes, it's "squash", not "fixup".

> >> Personally, I don't believe in squashing the commits of a PR/merge (I
> >> see the sub-history as important, not just the history of "this
> >> feature was merged in" - although for trivial changes, where there's
> >> one simple commit and then a follow-up to fix a typo or something,
> >> maybe it's tidier), but if that's what you want, I'd simply rebase the
> >> feature branch to squash it (at the same time as rebasing it onto the
> >> latest master), and then merge. Way WAY simpler.
> >
> >    Me too. I have never used squashed merge. But "branchiful"
> > development has its own troubles like problems with bisect.
> 
> Yes, it does. Most of the time, you can just rebase the commits into a
> linear history and run with it; since git retains separate Author and
> Committer names and timestamps, you can give proper credit to the
> contributor, while still ordering things appropriately. If you want to
> retain the history of "this group of commits did one job" without
> losing the commits themselves, you have to use merges. Otherwise, it's
> one or the other.
> 
> One of the beauties of git is that it allows myriad workflows. One of
> the great difficulties of getting started with git is that it allows
> myriad workflows. The curse of choice, multiplied out. :)

   (-:

> ChrisA

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

From barry at python.org  Thu Mar 17 18:00:02 2016
From: barry at python.org (Barry Warsaw)
Date: Thu, 17 Mar 2016 18:00:02 -0400
Subject: [core-workflow] GitHub Workflow
References: <20160317094844.GA23087@phdru.name> <ncee31$425$1@ger.gmane.org>
 <20160317171747.GA13430@phdru.name>
 <CAPTjJmoJDEnFLmzK05jy+tLcGjipzEGDqZD2ANJpxoyn8sABZQ@mail.gmail.com>
 <20160317174414.GA22135@phdru.name>
Message-ID: <20160317180002.0ed16e80@anarchist.wooz.org>

On Mar 17, 2016, at 06:44 PM, Oleg Broytman wrote:

>Me too. I have never used squashed merge. But "branchiful"
>development has its own troubles like problems with bisect.

Only when you don't have a clear main-line-of-development (like git <wink>).
But I usually don't squash merges or feature branches unless there's really a
lot of cruft, bisect issues not withstanding.

FWIW, here's GitLab's workflow:

https://about.gitlab.com/2014/09/29/gitlab-flow/

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

From brett at python.org  Mon Mar 28 13:44:35 2016
From: brett at python.org (Brett Cannon)
Date: Mon, 28 Mar 2016 17:44:35 +0000
Subject: [core-workflow] CLA bot is now live under the Python org on GitHub
Message-ID: <CAP1=2W5qbjL4Z-od+KZDBBiS=jbLJW+Okf00gUOV29M_Dz3GeQ@mail.gmail.com>

https://github.com/python/the-knights-who-say-ni is the new home for the
code. I also created the https://github.com/the-knights-who-say-ni bot
account for when I finally turn the bot on.

Ezio moved this weekend but told me he plans to commit Maciej's code soon
(I told him he could make GitHub usernames public which simplifies
matters). Once that's done and I have verified the CLA bot ties into the
new API on b.p.o properly I will then ask Senthil for his final
recommendation on how to convert Mercurial repositories to Git and then
move the devinabox repository over. If that move works out then I will
switch the benchmarks repository over. Once both of those moves have been
verified to have worked then we will figure out what's necessary to update
the deployment steps for the peps and devguide repos and then move those
two over as well.

Then the "fun" begins in doing what's necessary to get cpython moved over
(e.g. getting feature parity with the current setup).

Overall, the goal still remains to move all repos sans cpython over to
GitHub by PyCon US and the cpython repo itself by the end of the year.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160328/94589166/attachment.html>