Block Out-of-Date Pull Requests
By out of date, we mean a pull request that is based on an earlier version of the target branch. The problems with this are:
there may be conflicts, in which case it would not be mergeable
when the merge happens, the result is unknown - the merge result has not been built on either the topic or target branch
This will inevitably happen as changes are pushed or merged on to the target branch (for instance default
). But there is no reason why the pull request can’t be created from the tip of default
… this will give reviewers the best chance of being able to merge without conflicts, and a green build from the topic branch will mean you will get a green build after merging (as the inputs are the same).
We are trying to avoid this situation:
If a pull request is created from topic
now, the merge result is unknown, and it may be conflicted. If this listener is applied, you will see the message:
There is no need to lose any additional information that has been added to the description. In a command prompt window, rebase or merge your topic
branch:
git checkout topic
git rebase default
git push -f
Alternatively to merge rather than rebase:
git checkout topic
git merge default
git push
Once done, press the Create button again.
It’s possible that the developer will need to resolve conflicts when rebasing or merging the branch, however they were going to have to be resolved sooner or later, so better to do it sooner whilst it’s fresh in their mind.
Another way of ensuring that the merge will produce a green build, is to build from the automatic merge that Bitbucket will do when a pull request is rescoped (i.e. when either branch gets new commits):
git fetch origin +refs/pull-requests/{id}/*:refs/remotes/origin/pull-requests/{id}/*
where {id}
is the ID of the pull request in question. If there is no ref pull-requests/{id}/merge
it means there were conflicts. There is interesting further reading here.