On 7 March 2016 at 01:23, Paul Hoffman firstname.lastname@example.org 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.