[core-workflow] Spelling out a suggested local workflow for sending PRs?

[Paul Hoffman]

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>