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

Issue #5814 open
Anonymous 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

  • Claire Bianchi staff

    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

Comments (124)

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

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

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

  5. Mathieu Lemoine

    Come on guys! This is getting insane.

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

  6. Benjamin Echols staff

    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.

    Thanks,

    Ben Echols

    Senior Product Manager, Bitbucket Cloud

  7. Guyzmo

    Hi @Benjamin Echols

    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.

  8. Dewey Sasser

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

  9. 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/ bitbucket.org

  10. 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?

  11. Claire Bianchi staff

    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

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

    @Claire Bianchi

  13. Igor Baidiuk

    @Claire Bianchi 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.

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

    Cheers.

  15. Chris Morgan

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

  16. Log in to comment