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

[Donald Stufft]

> On Mar 7, 2016, at 8:17 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> That said, Chris's variant of just setting the upstream of the local clone's master branch to the upstream repo so "git checkout master && git pull" on master reads directly from upstream, while "git push" defaults to going to your fork, does sound intriguing - I'm going to try that on some of my existing projects where I made the original clone from my personal fork.


This is what I do, it works very well in my experience.

I also add a fetch line so that pull requests show up with refs and I can check them out locally. For example, here is my .git/config from one of my repositories: https://bpaste.net/show/2fd5a8dfe33e <https://bpaste.net/show/2fd5a8dfe33e>

This means that my ``master`` branch tracks the upstream, the default origin is my fork, and I can checkout PRs locally using:

    $ git checkout pr/N # Checks out the PR as a branch tracking the PR
    $ git checkout -b whatever upstream/pr/N  # checkout out the PR as a a new branch based on the PR.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160308/aab9faaa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160308/aab9faaa/attachment.sig>