<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, 6 Mar 2016 at 07:24 Paul Hoffman <<a href="mailto:paul.hoffman@gmail.com">paul.hoffman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I suggest that this be added to the new devguide, not a PEP, because there are many workflows that work for different people.<br></div></div></blockquote><div><br></div><div>Yep, this isn't policy but simply a suggestion, so it should go in the devguide.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br>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.<br><br></div><div>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.<br><br></div><div>I'm happy to write text up on this for the devguide when it gets time to do so.<br></div></div></blockquote><div><br></div><div>Great! Thanks, Paul!</div><div><br></div><div>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.</div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div></div><div dir="ltr"><div><br></div><div>--Paul Hoffman<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 6, 2016 at 1:27 AM, Oleg Broytman <span dir="ltr"><<a href="mailto:phd@phdru.name" target="_blank">phd@phdru.name</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That should be added to the new devguide or a PEP.<br>
<div><div><br>
On Sun, Mar 06, 2016 at 12:27:52PM +1000, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
> Something that came up at work recently was instructing people on how best<br>
> to configure local git clones for working with a "fork+PR" development<br>
> model, where you have your own server-side fork for the project that you<br>
> then use to submit pull requests. The trick is that there's an easy way to<br>
> do this and a hard way, and it isn't immediately obvious which is which :)<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>
> The hard way:<br>
><br>
> * clone your fork read/write<br>
> * still work in topic branches<br>
> * waste time keeping master in your fork up to date<br>
> * forget the previous step, and submit PRs against a stale version of master<br>
><br>
> I bring it up as when I first started using GitHub, the second way seemed<br>
> intuitively obvious to me, but it actually makes things harder than they<br>
> need to be.<br>
><br>
> Cheers,<br>
> Nick.<br>
><br>
> --<br>
> Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
<br>
</div></div><span><font color="#888888">Oleg.<br>
--<br>
     Oleg Broytman            <a href="http://phdru.name/" rel="noreferrer" target="_blank">http://phdru.name/</a>            <a href="mailto:phd@phdru.name" target="_blank">phd@phdru.name</a><br>
           Programmers don't die, they just GOSUB without RETURN.<br>
</font></span><div><div>_______________________________________________<br>
core-workflow mailing list<br>
<a href="mailto:core-workflow@python.org" target="_blank">core-workflow@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/core-workflow" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/core-workflow</a><br>
This list is governed by the PSF Code of Conduct: <a href="https://www.python.org/psf/codeofconduct" rel="noreferrer" target="_blank">https://www.python.org/psf/codeofconduct</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>
core-workflow mailing list<br>
<a href="mailto:core-workflow@python.org" target="_blank">core-workflow@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/core-workflow" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/core-workflow</a><br>
This list is governed by the PSF Code of Conduct: <a href="https://www.python.org/psf/codeofconduct" rel="noreferrer" target="_blank">https://www.python.org/psf/codeofconduct</a></blockquote></div></div>