Repository refs for pull requests

Issue #5814 open
Former user created an issue

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

Comments (170)

  1. Stéphane Wirtel

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

  2. Samuel Carlsson

    @matrixise actually BitBucket has a REST API. You could easily use this to build pull requests in your CI server. This issue I guess if more to make older CI systems work right out of the box.

  3. Eric Bower

    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.

  4. Dewey Sasser

    My team is going to move to a github subscription due to this issue. It's more expensive due to the number of repos but the impact of this lack on our workflow is significant.

  5. Chris Pinola

    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.

  6. Mathieu Lemoine

    Come on guys! This is getting insane.

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

    @Marcus Bertrand, @zdavis, @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...

  7. Benjamin Echols

    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'll post updates here as I have them.


    Ben Echols

    Senior Product Manager, Bitbucket Cloud

  8. Guyzmo

    Hi @bechols

    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!

    And the tool then implements it natively using:

    git hub requests ls
    # shows all PR for current project
    git hub requests fetch 42
    # creates a new branch requests/github/42

    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.

    My first attempt to implement this is the second option, and it's an understatement to say that I'm unhappy with it. And I believe that makes it a poor experience for project maintainers to work with bitbucket using that tool.

  9. Dewey Sasser

    @bechols 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.

  10. Rex Hardin
    git clone https://<url>/scm/<project>/<repo>.git <folder>
    cd <folder>
    git fetch origin refs/pull-requests/<pr-id>/from:<temp-branch-name>
    git checkout <temp-branch-name>

    ^ this works with BitBucket server, not sure if the ref is the same w/

  11. Gunter Grodotzki

    Can someone please simplify why this is required?

    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.

    Am I missing something?

  12. Claire Bianchi

    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.

    Thanks, Claire

  13. Rafsun chowdhury

    Without being able to test pull requests locally without merging them is making the whole Git use case point less. There is no need of making pull-requests if I have to merge them to check.

    Even if it takes you more time to make it like github you should provide some workaround so that we can at least make proper use of the pull-request thing.


  14. Igor Baidiuk

    @cbianchi2 Oh, please don't bother. I think all the people really interested already understood that Atlassian isn't interested in developing BitBucket, and already migrated to GitHub/GitLab.

    if being serious, this issue is already 6 years old. Enough time to rewrite whole project from scratch, at least twice, with your resources.

  15. Richard Bresnan

    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.


  16. Chris Morgan

    @cbianchi2 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.

  17. Cronje Van Heerden

    A workaround is to trigger a Bitbucket Webhook on the creation of a new pull request to an intermediary service (I used Zapier for simplicity). The Webhook information includes the commit hash of the pull request which can then be sent to the API of your CI server (Teamcity in my case). Much effort for something which would have been a one-liner with Github.

  18. Andrew St. Angelo


    We are working with a third party whose account and repo I don't have access to, directly. However, they have opened a PR against our Repo (because they DO have access to our repo) with code they forked off. I can see the code from the remote branch in Bitbucket but pull it down locally to test before accepting the PR. This seems a bit of a weird contradiction. I could spend an hour copying and creating files into my local branch but I can't pull down the foreign fork.

  19. Paul O'Riordan

    @Aneita Yang - As mentioned, this is a huge issue for us. We're unable to perform static analysis (e.g. SonarCloud) on pull requests due to this. Pipeline builds on pull requests only work if the pull request was created from the same repository, and not from a fork.

  20. David Chang

    Happy 6th birthday to this ticket! I would like to think very few major issues make it to this milestone unresolved.

    From what other Bitbucket staff have indicated, it seems like they strongly factor in how many votes are on an issue to provide direction in terms of what to tackle next ( So maybe we'll need to double our votes count to be taken seriously? 🙃

    Rather than waiting until 2024, I'll be porting over my projects to a different service for now. Good luck to everyone else who's also been waiting for a few years on this one!

  21. Nick Medrano

    I am a single team/developer that recently discovered and wanted to utilize the deploy+preview feature. Unfortunately, looks like Bitbucket is not able to do this with Netlify. I will watch this issue.

  22. Alastair Wilkes staff

    Hi y'all -- thanks for your feedback and patience on this issue. On the pull requests front, we are currently focused on improving the new PR experience (currently in beta). That said, PR refs are an important feature, and this issue is high on the priority list in the backlog.

  23. tucaz

    It is crazy the world we live in nowadays. If you look at Instagram accounts from Atlassian employees you see how much "kudos" and pats on the back they get every day. On top of that, there are a bunch of events, beer nights, dinners, lunches and all sorts of get-together. In the meanwhile, paying customers have to wait years and years for a feature that is available pretty much everywhere else to come out, if it ever comes out.

    It must be great to live in this bubble where you don't have to deliver what your customer needs in order to get a pat on the back and multiple "kudos" and can party instead of work.

    I'd like to vote with my dollars, but unfortunately, that decision is not up to me. If it was, I'd be out of Atlassian products faster than one could say "kudos".

  24. Per Gårdebrink

    While waiting for this feature, I did a workaround for it using bitbucket pipelines that might interest others perhaps.

    Since pipelines has support for triggering on pull requests (both when created and when new commits are added), I created a pipeline that looks similar to the one included here below (our implementation looks a little bit different in order to trigger TeamCity to build and report back build and test status that can be visible inside the pull request). It will spend pipelines billed time, so take that into consideration first (for us, each pipeline takes about 45 seconds)!

    image: node:10.15.0  
          - step:
              name: "Push resulting merge of a pull request to git"
                - echo "Creating merged branch for pull-request ${BITBUCKET_PR_ID}"
                - git branch -f pull-requests/${BITBUCKET_PR_ID}/merged
                - echo "Creating head branch for pull-request ${BITBUCKET_PR_ID}"
                - git checkout ${BITBUCKET_COMMIT}
                - git branch -f pull-requests/${BITBUCKET_PR_ID}/head
                - git push origin pull-requests/${BITBUCKET_PR_ID}/merged --force-with-lease
                - git push origin pull-requests/${BITBUCKET_PR_ID}/head --force-with-lease

    Once a pull request is created and later updated, the head and merged branch with the corresponding id will be updated (the created merged branch will point to a merge between the PR source and destination)

  25. Log in to comment