On Mon, 7 Mar 2016 at 09:23 Barry Warsaw <ba...@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.
_______________________________________________ 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