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

[Oleg Broytman]

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.