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@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@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@gmail.com   |   Brisbane, Australia

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

_______________________________________________
core-workflow mailing list
core-workflow@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@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