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

  • 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

Comments (106)

  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. Log in to comment