Manually closing bitbucket's pull request

Question

My question

I do things like that:

git clone
git checkout -b new_feature
< work and commit >
git rebase master
< work and commit >
< finish working >
git rebase master
git push origin new_feature
< I create pull request via bitbucket's web interface >

Someone who reviewing the changes is doing:

git pull
git checkout master
git merge --squash new_feature
git push origin master

I was hoping this will close the pull request as accepted but it did not, what am I missing?

Some background information

I read lots of bitbucket's documentation "working with pull requests" but this is still not clear for me.

I can see all my commits from new_feature branch have been applied to the master branch (via git merge --squash) and I can see which files have changed, but now when I press "merge" on a bitbucket's pull-request interface I have another commit in master which is merge and this does not change any files (all the changes were already applied by previous git merge --squash) but just brings all those commits history into the master which is not what I wanted.

Via: https://confluence.atlassian.com/display/BITBUCKET/Working+with+pull+requests

Manually pulling requests to your local system

Sometimes it is a good idea to use a workflow where you test a changeset on your local system before accepting a pull request. You can do this with any pull request. The typical workflow is this: Receive a pull request in Bitbucket. Update your local repository with the incoming changeset. Investigate and/or test the change set. If you the change set is good, you merge it into your local repository. You may have to resolve some conflicts. Then, you push the local repository back to Bitbucket. Back on Bitbucket, the pull request is marked as accepted in the Pull requests tab. If you don't like the change request, you discard the changes locally and reject the pull request on Bitbucket. Ideas?

Solution 1

As I understand it, there are two ways to close a Bitbucket pull request as "Merged".

1. Click the 'Merge' button. Bitbucket will merge your feature branch into the destination branch. (Newer versions of Bitbucket allow you to choose between --no-ff and --squash strategies. Older versions implicitly use --no-ff.)
2. Use git console commands (or other interface) to merge your feature branch into your destination branch, then push both to origin.

The first option is definitely the easiest and most straightforward, but it does not work well with certain development workflows.

The key to getting the second option to work is that your feature branch must be on your destination branch. Bitbucket checks periodically for pull requests that have been merged manually and, when found, automatically marks those pull requests as Merged. Note: Atlassian does not advertise this behavior. I was not able to find any official documentation supporting this claim, but at least one other person out there has seen it work.

Based on the workflow you described, I'm guessing the person who reviewed and pushed your changes has a git history that looks something like this:

*   ddddddd (origin/master, master) new feature, squashed
| * ccccccc (origin/new_feature, new_feature) new feature part C
| * bbbbbbb new feature part B
| * aaaaaaa new feature part A
|/
o

In this instance, the simplest way to have Bitbucket automatically close out the pull request would be:

git branch --force new_feature ddddddd
git push --force origin new_feature

This also works for feature branches that have been rebased.

WARNING! Keep these facts in mind:

• Not all workflows allow force pushes of this sort.
• Bitbucket automatically updates the commits shown by a pull request whenever its feature branch changes. Depending on the order in which you push your branches, this can result in an empty commit listing. (More on this below.)
• When a pull request is closed, any commit history and diff information are frozen.

When you push your destination branch to origin before you push your feature branch, Bitbucket first looks for any commits on the newly pushed feature branch that aren't on the destination branch. Since the new feature branch is an ancestor of the destination branch, the result is empty set. Bitbucket therefore removes all commits from the commits tab of the pull request, which now reads, "There are no changes." Then, since the feature branch is in the destination branch's history, Bitbucket closes the pull request, freezing the empty commits tab as so:

Curiously, the diff remains intact in this case.

If none of the above merging options work for you, your only remaining options are:

• Decline the pull request.
• Consider changing your workflow to something Bitbucket more easily supports.
• Float a feature request with Bitbucket/Atlassian.

See also documentation for git-branch and git-push.

Solution 2

UPDATE

As of 31 January 2017 a feature was implemented to address the inability to close PRs manually.

Please refer to (and upvote!) the answer by @BenAmos for details.

---

Original Answer

^{(kept for historical purposes)}

You are not missing anything. Bitbucket does not automatically close your pull request when it has been merged.

You have to manually close the pull request yourself by selecting the "Decline" option.

Solution 3

BitBucket Server 4.5.1 modified how remote merges are classified in the pull request (i.e. declined or merged).

@BenAmos 's answer above works well, but if you push the merge commit to the destination branch BEFORE force pushing onto the feature branch, BitBucket will automatically close the pull request and classify it as 'declined'.

However, if you instead force push onto the feature branch BEFORE pushing the merge commit to the destination branch, BitBucket will automatically close the pull request and classify it as 'merged'.

From Atlassian: "A pull request will now be declined after a push if: there are no commits on the from-branch that are not also on the to-branch AND the to-branch has not been updated in the same push"

Reference: https://jira.atlassian.com/browse/BSERV-4219?src=confmacro&_ga=1.138319284.547646488.1457297841

Solution 4

I guess, bitbucket does not recognize your PR as merged, because git merge --squash produces a completely new commit. In our company we also tried git merge --squash feature branches when merged them into main branch, but gave it up because pull-requests merged this way kept hanging around, and later we needed to "Decline" them or remove the related remote feature branches.

What we are currently doing is squashing all feature branch commits into one and force pushing it to a remote feature branch. After that, the person responsible for merging into master just need to click "Merge" on the bitbucket's pull request page and that is it, the PR is marked "Merged" and all changes introduced in the feature branch are squashed into a one neat commit.

View more solutions

Comments

[wberry]

Please update the question with what you are trying to do, or to understand.

[Tri Nguyen]

I am trying to do the same thing as well, and cannot figure out an ideal solution either. After doing a merge squash locally on master and push it upstream, I then had to manually "Merge" the open PR, which has a 0 changeset.

[Potherca]

The ideal solution is to not manually merge pull requests but use the BitBucket UI. If you must edit the PR locally, there is no ideal way. :-(

[Laoneo]

There is a feature request open for bitbucket bitbucket.org/site/master/issue/8995/…

[Tri Nguyen]

This will mark the PR as declined, which is not correct because it was in fact merged.

[Potherca]

You are right. I updated my answer to more clearly reflect this.

[Potherca]

@RobinGreen You can't. Declining is the only way :-( I'll reword my answer to make this more clear.

[vaskort]

Yeah happened to me too, merged manually through console and my pull request on Bitbucket got updated

[simon]

Same for me. There's just a lag between merging and status change. The answer above with the 'decline' solution is false!

[Potherca]

@lime Good to see things have changed on Bitbucket. The solution did not work in the past. The issue for this is still open though: bitbucket.org/site/master/issues/8995/…

[Potherca]

@Jeffpowrs I see more and more companies moving toward Gitlab in favour of Bitbucket. Your company might want to follow the trend. Otherwise, there's always other more-developer friendly companies out there :-)

[Ajoy Bhatia]

@BenAmos has the better answer, saying that Bitbucket periodically checks for pull requests that were merged manually and marks them Merged. That was posted on Dec 16, 2015 so it is possible that this feature was added after this answer, though I don't know if that's true.

[Potherca]

@AjoyBhatia This answer was posted before the feature was implemented by Atlassian. The issue I mention in a previous comment was resolved in early 2017.

[Ajoy Bhatia]

@Potherca - OK. Got it. Thanks for the update on the answer. Upvoted it.