Allow pull requests to be closed without "declining" after a branch is closed & merged locally.

Issue #13380 open
Chris Phillips created an issue

If branch being reviewed by a pull request happens to be closed and merged back to the target branch outside of BitBucket's Pull Request, the only way to close the Pull Request is to "decline" it. This makes it look like the change was rejected, when in fact it was accepted.

Most of the time, our devs want to just use the "merge" button for a Pull Request to merge back to the target branch, but we can't guarantee that's always the case. For example if a there are conflicts in the merge to the target branch, they'll have to be resolved locally and the user may want to just handle the merge back to the target branch at the same time. Having to mark the pull request as "declined" in this case leaves a false trail of history that makes it look like the change should have been rejected rather than accepted.

Comments (10)

  1. Kaleb Elwert Account Deactivated

    If a branch is merged locally (without rewriting history), it should be marked as merged. If history is rewritten locally, there's nothing we can really do, so we see that the branch is closed and mark the pull request as such.

    If you want to ensure a PR is marked as merged rather than declined after rewriting history, make sure to push that branch up again before merging.

    If this isn't the behavior you're seeing, can you provide an example repo/PR so we can try to debug this?

  2. Chris Phillips reporter

    Thanks for getting back to me on this so quickly!

    I tried creating a test repo for this with a test pull request.

    Here's what I did to setup the test repo:

    • Created repo
    • Added initial changeset on default ( ad21109 )
    • Created "mybranch" ( 95bc5ad )
    • Pushed the repo up to BB (2 new changesets)

    At this point I created the pull request for mybranch -> default in the BB UI.

    Then, back on my local machine:

    • Closed "mybranch" (95bc5ad)
    • Merged "mybranch" back into "default" (0dafa4a)
    • Pushed the repo up to BB (2 new changesets)

    At this point I looked at the PR in BitBucket and it just looked "normal", with the "Merge", "Approve", "Decline" buttons. Out of curiosity, I clicked "Merge" and got the merge dialog, then proceeded to accept and the PR is now marked as merged (with no further changes to the repo).

    This actually all seems fine to me -- just two oddities to note:

    • My team mentioned that this didn't work on our (much larger) private repository. Maybe they misunderstood, or maybe the much larger repo is a problem?
    • The PR did not auto merge as you seemed to state should be the case above.

    Thanks for looking into this -- if you're comfortable with the above oddities, please feel free to close this issue.

  3. Kaleb Elwert Account Deactivated

    I'm not as familiar with how the auto-merge code interacts with hg, so I'm going to pull in @seanfarley to see if he knows anything about this.

    One thing worth noting: we do these updates in background tasks, so for larger repos it stands to reason that it would take longer to update.

  4. Sean Farley
    • changed status to open

    Interesting. I was able to reproduce this locally. I have a fix for this but I'm curious to know what changed on our end.

  5. Sean Farley

    I've managed to fix this locally. I'll submit this and hopefully it'll get reviewed / merged this coming week (then most likely deployed the week after).

  6. Timothy Harris

    I ran into the same issue. The only difference being our CI server who is doing the merges and pushing back to the repository. We have set branch permissions on specific branches so that only our CI server is allowed to merge towards them. So this is quite painful for us...

  7. Log in to comment