[ntalbott]

Using git remotes and distinct branches per contribution is totally legit, and I still do it sometimes. But, I'm often/usually dealing with contributions that have already been reviewed and don't need a whole feature branch/review within the root repository before inclusion. And for that setup - where it's almost ready - it's so much easier to just `git am` it into master, make necessary tweaks, and push.

In general I'd just encourage maintainers to try the `git am` flow, especially on small to medium complexity contributions where it looks mostly ready to go and you don't want to do another week of ping-pong with the contributor just to get a variable renamed or some whitespace fixed.

As I tell my kids, "Just try one bite of <food I find delicious>. If you don't like it, that's cool, then it's more for me!" :-)

[eevilspock]

What about submitting a PR with your cleanup to the original PR's branch? That person reviews and accepts, then submits a new PR back to you.

I haven't learned git yet so maybe my assumption that the original PR is on a branch/repo clone to which you can submit a PR is incorrect?

[jessaustin]

You totally could do that, but it doesn't really help with the lack of interest problem he described. If the contributor can't be arsed to fix their patch, can we expect them to be arsed to merge a patch to their patch and then re-PR it?

[gknoy]

Since PRs on Github auto-update when the branch they are based on is updated, they would not need to create a new pull request:

Bob requests that Alice merge bob/bob-feature into alice/master.

Alice requests that Bob merge alice/fix-bob-to-conform-to-pep8 into bob/bob-feature.

Bob merges that into bob/bob-feature, and Bob's PR into Alice's repo is now auto-updated to reflect the changes that he merged into his branch.

Alice is now satisfied, and merges bob/bob-feature with alice/master.

[jessaustin]

Good point; thanks for the info! Under the hypothesis that Bob is lazy, however, he still might not perform that merge...