On Sun, 6 Mar 2016 at 07:24 Paul Hoffman <paul.hoff...@gmail.com> wrote:
> I suggest that this be added to the new devguide, not a PEP, because there > are many workflows that work for different people. > Yep, this isn't policy but simply a suggestion, so it should go in the devguide. > > One category of workflow is "make a clone on GitHub for each suggested > patch, then nuke that clone and start over for the next patch". A different > category of workflow is "clone on GitHub, clone from there to my local > machine, and keep my local machine up-to-date with the origin so I can keep > putting in patches easily". And there are other workflows that are > supported by different small tooling. > > FWIW, I still don't know which I prefer. We are having this issue in the > IETF, and it is clear that people don't all agree on what they prefer. > > I'm happy to write text up on this for the devguide when it gets time to > do so. > Great! Thanks, Paul! My hope is that we get the devguide moved over early so that we can create a "github" branch to hold the GitHub-related changes so that as soon as cpython is ready to switch it will take nothing more than a merge of the branch into `master` to make the changes appear online. -Brett > > --Paul Hoffman > > On Sun, Mar 6, 2016 at 1:27 AM, Oleg Broytman <p...@phdru.name> wrote: > >> That should be added to the new devguide or a PEP. >> >> On Sun, Mar 06, 2016 at 12:27:52PM +1000, Nick Coghlan < >> ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia >> >> Oleg. >> -- >> Oleg Broytman http://phdru.name/ >> p...@phdru.name >> Programmers don't die, they just GOSUB without RETURN. >> _______________________________________________ >> 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 >> > > _______________________________________________ > 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
_______________________________________________ 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
