Issue #6952 wontfix

Manually accept pull request without making a merge commit (BB-8109)

Oleg Oshmyan
created an issue

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 #6704. The difference is I don’t want a relationship between two pull requests; I only want to manually override the status of one.)

Comments (18)

  1. Dylan Etkin

    Hi Oleg,

    Sorry you were having troubles with this.

    If you were just going to fulfill the PR as the site would have done so then pushing up the merge will automatically close the PR.

    If you fulfill with different commits then your only real choice is to reject the PR. I think your usecase is a pretty small portion of what is happing so we are not going to fix this right now.

    Thanks for understanding, cheers,

    Dylan

  2. Oleg Oshmyan reporter

    Thanks for your response.

    But I have to wonder, is fixing minor things in a pull request (and/or rebasing it) really an uncommon use case? Do most people like their history cluttered with merges and follow-up edits? Mercurial is even developing a brand new changeset evolution system to better support the workflow I described—surely this means enough people use it. For what it’s worth, I know GitHub’s second most-forked non-example repository, Homebrew, uses it consistently and almost exclusively: if they always asked contributors to rebase and fix even the smallest of things on their own, they wouldn’t be able to keep up, nor to keep their history clean. We also have the submitter of #6704 here.

    Is there a preferred Bitbucket-compatible workflow that achieves the same result? Ideally I want (1) all my commit comments to be retained, (2) only the fixed commits to go into the master repo, and (3) the pull request to be marked as accepted. It’s just a marker after all. How do you do pull request evolution in the Bitbucket team?

  3. Colin Caughie

    Not sure if this is related, but I just had a similar problem - but this time the changeset I manually pulled was identical to the one in the pull request, and still it didn't close the pull request. The reason I did it manually was that when I hit the Merge button it just gave me a wait indicator for a really long time and never carried out the merge.

    In any case I agree with Oleg; given that you can manually accept (and modify) a pull request, the lack of a "mark as accepted" feature seems like a pretty glaring omission.

  4. Erik van Zijst staff

    but this time the changeset I manually pulled was identical to the one in the pull request

    Colin Caughie "Pulled"? Or do you mean pushed?

    FWIW, this morning (about the time you left this comment) we had a problem with our background tasks which lead to a very long delay in processing. Since auto-fulfillment of PRs in response to manual pushes is performed in background tasks, I wonder whether that is what bit you.

    Let me know if you are structurally seeing this problem and if so, please contact support@bitbucket.org with details about the repo, the actual commits in the push and the PR details and we'd be happy to have a closer look.

  5. Erik van Zijst staff

    Oleg Oshmyan Contrary to what Dylan Etkin suggests, we do attempt to detect git rebases of open pull requests and we should indeed allow you to update the PR by clicking "edit" after you pushed the rebase.

    Or are you talking about pulling down the source branch, rebasing/rewriting it, then merging the rebased version into the destination branch and then pushing the result up to the dest branch in Bitbucket? If that's the case then no there's very little we can do to pick up on that, as we can't recognize those rebased commits (with different SHAs than those on the source branch) as the stuff in a particular PR.

    If however you mean you pull down the source branch, rebase it and force-push it back up to the source branch (without merging anything into the dest branch), then yes, Bitbucket should allow you to first update the PR to track the new source and then fulfull/merge it (which in git will always create a merge commit, even for ffwd merges).

    Please reopen this issue if can provide steps to reproduce this problem.

  6. Chris Cannell

    Dylan,

    I think there is speculation that the utility only applies to a small group. GitHub has this feature, although it is unclear how often this feature is used on GitHub.

    https://help.github.com/articles/closing-a-pull-request

    I have run into this use case several times where I wanted to do a fast-forward merge but merging through a pull request forces a non fast-forward merge. I would be satisfied with an option to do a fast-forward merge in a pull request.

  7. Andy Atkinson

    I am new to BitBucket having used Github (public and enterprise) pull requests for years, and find the "reject" term strange. My typical usage is to publish a PR, collect feedback, then perhaps branch off master again if I want to exclude portions of the original branch, based on feedback. I'd like to "close" the original PR at this point, manage it myself in other words, as it is obsolete. I personally think a button label of "close" instead of "reject" captures that intent better. Thanks.

  8. Germano Percossi

    Oleg Oshmyan , do not worry, you are not the only one having this problem and this is not uncommon at all.

    I have to admit I pushed my team towards Bitbucket in the old days when it was not so Git-centric.

    Now we are using GitHub and, sorry to disagree, but in GitHub you can apply patches manually or merge after a rebase (yes, changing the hashsum) and be able to close the Pull Requests. This is done using special tags in the commit message.

    Not every project likes to have its history cluttered with unnecessary merges or not being able to add last minute changes at a commit message (e.g. Acked-by tags) because of the impossiblity to close the PR if the SHA is changed.

  9. Gary Oberbrunner

    Another vote. I'm one of the maintainers of the SCons project. For whatever reason, about half the commits I manually accept and merge (via hg), bitbucket doesn't detect that I've done that and I have to close them as declined, and explain to the poor developer that it was really accepted. This is really annoying and makes SCons look unprofessional.

    (I almost never use the bitbucket buttons to accept; we have to run our test suite first among other things.) All I want is "mark accepted."

  10. Peter Shangov

    Another vote for rebase/merge-squash. Approximately half of our pull requests end up being merged this way, and making Bitbucket happy only adds extra admin work with no real benefit.

  11. Mark Rekveld

    Another vote! I would really like to see a simple "Mark as Accepted" button. This would allow us to use the PR within Bitbucket for our review process but with the option to merge differently.

  12. Roman Starkov

    Come on, just because I need to merge differently or make a tweak doesn't mean I've rejected the PR! But if people look at the project's history, they'll see lots of "rejected" PRs and possibly refrain from sending one.

    At least let us accept-by-rebase.

  13. Log in to comment