<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 7 Mar 2016 at 09:23 Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mar 06, 2016, at 12:27 PM, Nick Coghlan wrote:<br>
<br>
>The easy way:<br>
><br>
>* clone the upstream repo read-only<br>
>* add your fork as an additional read/write remote:<br>
>  * e.g. "git remote add pr <URL of fork>"<br>
>* work in a branch<br>
>  * e.g. "git checkout master && git checkout -b issueNNNN-summary-of-issue"<br>
>* publish via your fork, and then submit back to the main repo<br>
>  * "git push pr"<br>
>  * use the web UI to submit the PR<br>
<br>
This is essentially what I do too, but with some differences in names.  Chris<br>
mentioned naming the 'upstream' remote to point to the upstream repo, and<br>
'origin' to name his clone.  I do something different, but as a general<br>
recommendation to people who are coming to this workflow previously unscathed<br>
<wink> I like Chris's suggestion.<br>
<br>
I generally only name my issue branches after the issue number,<br>
e.g. "issue1234" since I can always go to the tracker to find details, and<br>
these shouldn't be long-lived branches anyway.  I'd likely name a big feature<br>
branch differently.<br>
<br>
I think the essential bit of Nick's "easy way" is that you pretty much ignore<br>
your fork's master.  It's just too much work to try to keep it sync'd against<br>
upstream master.</blockquote><div><br></div><div>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`.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  Just do a pull of upstream master when you're starting<br>
something new, and push your branches to your own fork (and many people won't<br>
be able to push to upstream's repo anyway).  Then use the web ui to create a<br>
pull request from that.<br></blockquote><div><br></div><div>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.</div></div></div>