[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.

[jedbrown]

Oh, I thought you meant updating the pull request by force-pushing on their branch. Your solution is racy, thus only acceptable for projects small enough that the likelihood of someone pulling during that window is sufficiently low.