Refify pull requests by making them a ref in the repository (BB-7014)

In Github, pull requests sent to repo can be accessed via refs/pull/123/...
This enables things like Travis CI to work.
I'd like the pull request be reified here, as well, so I can access it from git itself.
Also, allow to list pull requests (possibly with filtering for open ones only), but there is #3442 for this.

Official response

We are currently working to improve the pull request experience. The first phase of this will be launching in the next few months. Our backlog includes a variety of new features and enhancements for pull requests and this is one that we are considering.

Please continue to follow this ticket for updates, and add comments describing any use-cases that are important to your team and not already covered above.

+1 What do you wait for this feature? Sorry, but I work on a Continuous Integration Server, and this feature is missing :/ And currently, I can't support Bitbucket just because of that. I don't have the problem with GitHub.

How are we supposed to test a PR before merging it? The only way I've found to get around this is getting READ access to the person who is submitting the PR's repo and then adding it as a remote. At the very least the maintainer of a project should be automatically be granted READ access to the forked repo so maintainers don't have to ask for READ access.

Doesn't seem to be working for me when PRs are sent from private forks, but apparently Bitbucket Server (at least unofficially) has some support for exposing PRs via the refs/pull-requests/*/from and refs/pull-requests/*/merge refs. Source.

Could we at least have some form of acknowledgement from the bitbucket team !?

@Marcus Bertrand, @Zachary Davis, @Jonathan Mooring, you are aware this issue exists since you acted on it. Any chance you could give us some feedback or push this on the desk of someone who could? After 4 years and several people saying they left bitbucket because of this, not a word...

I'm currently using bitbucket only because I'm forced to do so (I don't have the control on the project). As long as this issue isn't solved, I will never recommend it to any customer or colleague. Interacting with PR whether they come from private repos or not is really basic... An we're talking about something impacting paying customers and preventing them to adopt Industry Best Practices here...

This is indeed something we want to add to Bitbucket. I can't provide a timeline - this will be a significant engineering effort - but improving the code review experience is a priority for us. As mentioned earlier, the build status API enables many CI/CD workflows, but we do understand the use case for PR refs.

I'm writing a tool called git-repo who tries to offer a clean and homogeneous CLI access to git services like bitbucket (and github and gitlab and gogs…). In the other two tools (gogs implementation is pending), fetching requests as refs is possible, but not in bitbucket!

Then if the user makes a change, you just get it by doing a git fetch of that change, and it makes reviewing and/or merging pull requests very simple and almost seamless when using the git CLI.

Trying to implement that feature for bitbucket, I have two options: either I make a new remote with the source repository where the change comes from, or I get the patch and apply to a branch.

The first case is bothering because it complexifies the implementation too much, and enforces making a few naming conventions for git remote's space. The second is so that getting new updates from a fetch is if not impossible, hard or is likely to overwrite local changes.

@Benjamin Echols FYI, I really tried to stick with bitbucket, but ultimately the inability to try out the changes locally without the chaos of dealing with others remembering to give permissions to private forks was taking up too much time. I've moved all of our significantly collaborative projects to github.

I'd really enjoy having this feature, so I can consider moving them back.

We have plans to stop using Bitbucket only because of lack of Upsource support ( related integration issue https://youtrack.jetbrains.com/issue/UP-5943 was closed by JetBrains, no one want wait you for several years )... Good that we have another choices (GitHub, GitLab)... Bitbucket is not bad but very slow development...

Currently I use a separate/real bitbucket-account that has to be added with read-rights to forks. That is also the user that will clone the pullrequest (which is just a branch on the fork) and build the application on jenkins.

We are currently working to improve the pull request experience. The first phase of this will be launching in the next few months. Our backlog includes a variety of new features and enhancements for pull requests and this is one that we are considering.

Please continue to follow this ticket for updates, and add comments describing any use-cases that are important to your team and not already covered above.

This may have been implied by some of the previous comments, but I'd like to make it an explicit requirement that Git refs are included for both same-repo pull requests and cross-repo (or forked repo) pull requests.

Our customers fall into both categories: some use same-repo PRs, and others use cross-repo PRs. This feature should support both cohorts.

@Claire Bianchi In your last comment from March 2018 you said you are working to improve the PR experience and "this is one that we are considering". Can you update the status of this to let us know if accessing a PR as a reference is going to be included in those PR enhancements or not.