That should be added to the new devguide or a PEP.
On Sun, Mar 06, 2016 at 12:27:52PM +1000, Nick Coghlan <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia
Oleg.
--
Oleg Broytman http://phdru.name/ p...@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
