You can create a new branch containing the pull request fairly easily.[1]

It's just: git fetch origin pull/ID/head:BRANCHNAME git checkout BRANCHNAME

Edit: I see that MaikuMori[2] posted the same information just before me; ah well.

[1]: https://help.github.com/articles/checking-out-pull-requests-...

[2]: https://news.ycombinator.com/item?id=7949107

I appreciate it! I had no idea that this was possible.

>The simple solution, though, is to require pull requests to come in a feature branch, and flat out reject any that target master. /shrug

Agreed, and in my experience, every major open source project I'm familiar with requires pull requests to feature branches. In fact, most small projects use the same workflow.

Is this not the case with most open source projects?

...and I believe the key word here is 'major'.

There are a lot of small, one-off, often very useful utilities that people are now sharing with each other via Github (I'm guilty/a participant in this phenomenon), and many noble users of these utilities want to help, contribute, and send PRs... a non-negligible number of them new to Git.

So, is it more of a PITA to set up a feature branch for a single python script and instruct users in your CONTRIBUTING file to 'make sure they submit PRs to branch XYZ!' or just deal with the odd occasional PR to master? Folks new to Git will probably just send a PR to master anyway (I believe OP addresses the 'new user' issue as well, having to explain Git commands to users in comments on a PR)

That all being said, I still typically follow the workflow shadowmint outlines above.

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!" :-)

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?

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?

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.

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

Agreed. Having a pull request go to a feature branch (or bug branch, or whatever your pull request is aiming to do) is the best way to go about it.

The issue described by the author is definitely more of a workflow problem than a technology or service problem.