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?

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