On 7 March 2016 at 01:23, Paul Hoffman <paul.hoffman@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.
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".
The audience here is folks that don't already have a preferred workflow for interesting with GitHub repos, so it's mainly that second one I want to advise people against using - having used it myself as my primary approach for working with GitHub repos until recently, I've found it to be a recipe for submitting PRs against a stale checkout of master, which then need to be rebased before they can be properly reviewed. That's a pain for both submitters and reviewers, but it's not obvious the problem exists until you've been using the approach for a while. The "ephemeral clone" approach is certainly an available option, but it's significantly more work for each patch than a persistent clone, and also doesn't tolerate having multiple PRs in flight at once, so I'm less worried about people choosing it naively without realising the additional hassle it causes. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia