[core-workflow] Spelling out a suggested local workflow for sending PRs?

[Nick Coghlan]

On 7 March 2016 at 01:23, Paul Hoffman <paul.hoffman at 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 at gmail.com   |   Brisbane, Australia