Ability to accept/resolve a pull request without making a merge commit

I receive a pull request, I comment on it, I pull it to my computer, I edit the commits locally to address the issues I point out in the comments, I push the edited version to my repository. I return to the pull request to accept it… but what’s this, Bitbucket wants me to either make a merge commit or decline the pull request?

Okay, let’s see, I have admin access to the source repository. Surely I can just push my new commits to it and edit the pull request… No, it only lets me choose a whole named branch as the source rather than any particular head. Let’s try closing the original head… Good, it’s gone. But wait, why can I no longer edit the pull request—and more importantly, why does Bitbucket still want me to merge in the original commits?

For God’s sake, please add a button labelled ‘Mark as Accepted’. I don’t want a merge commit. Neither do I want the pull request to automatically re-open when I merge and then modify or strip one of the commits I merged in. I just want Bitbucket to trust my judgement and permanently keep the pull request as accepted.

(See also: issue BCLOUD-6704. The difference is I don’t want a relationship between two pull requests; I only want to manually override the status of one.)

(04/13) edited by 8fe7ca997d35: 
We noticed another case where the customer mentions that when he uses squash merge in a Pull Request, the strategy is not recognized, and there is no indication of the merge on the git history.

When the Pull Request has a conflict and the conflict is resolved locally via a Squash merge followed by a push, the PR does not get updated as MERGED status and it remains open. The diff shows as empty as the merge are already there.

Also, the only workaround is to decline the PR, which is not a good option since the customer wants to keep the track of the history.