[caf]

What would increase the accept rate greatly would be if there was a function to accept-pull-into-new-branch, which creates a new branch and applies. The maintainer can then apply the necessary changes/corrections/documentation updates, get the branch tested, then merge it back if all goes OK.

[jedbrown]

    $ git fetch url-or-remote their-branch-name:my/better-branch-name
    $ git checkout my/better-branch-name
    $ hack, commit, etc

[caf]

I'm aware you can do that with native git, of course - but that leaves the original pull request on github appearing "unapplied", doesn't it?

I meant that it would be useful to add a function for that workflow in the github UI.

[jedbrown]

If you edit commits in the branch, then yes, it appears as declined in the UI, which looks hostile when they are notified. I write a friendly message every time I do this, but it sucks to have to give that explanation and the UI metadata is still wrong. I asked for this on bitbucket, though it's currently on hold [1].

If you don't edit the existing commits, then it will show up in the github/bitbucket UI as merged when you eventually merge, regardless of what games you play with branches.

[1] https://bitbucket.org/site/master/issue/6704/supersede-pull-...

[plorkyeran]

One way I've worked around this is to merge the original pull request, then immediately force-push the fixed version. Still doesn't fix all of the UI metadata, but at least the pull request gets marked as merged.

[jedbrown]

Only works when you have push access to the repository that is the source of the PR. Normally maintainers don't have access to the repositories for all contributors.

[plorkyeran]

Er, no? You merge the unfixed version via the web UI (to get the PR marked as merged), then immediately force-push the fixed version to your own repo, not their's.

[steveklabnik]

You can do that. Just see what branch the pull request is on, then git pull it, followed by a merge of FETCH_HEAD.