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

[Brett Cannon]

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>