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

[plorkyeran]

It's definitely not an option for very large projects, but projects small enough to have a very low chance of someone pulling in a several second window describes the vast majority of projects (and in general by the time it gets unsafe I'd expect fixing up incoming pull requests to be impractical time-wise anyway).