1. Bitbucket Website
  2. Public Issue Tracker
  3. master

Issues

Issue #2998 resolved

Support pull requests between two branches in the same repository (BB-2433)

Michael Cameron
created an issue

Pull requests can be used as a method for review between feature branches and the default branch (github supports this) within the same repository. This could support better intra-team reviews and interaction. Accepting the pull request would merge the changes into the default branch (or branch in question) and optionally closing the source branch.

Comments (30)

  1. Dylan Etkin

    Hi Michael,

    We are aware of this limitation and you are right, there is no need for it.

    We have an issue on our backlog to address this, its just a matter of finding the time and figuring out how best to present the UI/UX.

    Thanks for reporting,

    Dylan

  2. Jeffery Price

    I'm curious about the enforceability of this without branch-based permissions within a repo, while also simultaneously concerned that branch-based permissions within a repo would add too much complexity/noise within the repo and its history.

    Assuming a team of developers all has write access to the common repo (to effect offsite backups of ongoing work), wouldn't branch-based pull requests be non-enforcable? Wouldn't they just be a procedure that should be followed rather than one that cannot be bypassed? In other words, couldn't any developer with write access just merge and push without the desirable and intended pull request/peer review step?

    To truly enforce the pull request/peer review process, then, wouldn't you still need a separate repo with more limited write access?

    I'm not a github (or git) user and unsure how they handle this. But I'm interested in the functionality. But it seems to me that to really enforce this, multiple repos would still be necessary. Or, with branch-based permissions, you could use a single repo but the complexity would be about the same with the side effect that your repo history would be much more noisy.

  3. Michael Cameron reporter

    I don't see the need for systemic enforcement. I do see it as a procedure that just should be followed, but could just as easily be bypassed. Write access to the repo is liking giving someone admin rights. You trust that they'll follow appropriate processes to perform various activities, but once you've handed over the keys you can't stop them from doing something stupid.

    Branch-based pull requests can support a team process that should see most/all work performed in branches and only merged in on review. Just as with admin rights, someone with write access can either commit work in the default branch, or merge in work without a review, and that might be appropriate in certain situations. If someone abuses those rights then the team should handle that on their own.

    We recently moved some repos from bitbucket to kiln (we didn't want to convert the actually repo to git, so github was not an option) only because we wanted a review mechanism tied in with our source control. There is no enforcement, since it is just a layer atop a normal mercurial repo, and in fact the review is not even tied into a branch or pull request, and there is no mechanism to do the merge after the review is complete. The entire branch, modify, review, merge process is entirely outside and unenforced by the system, it is de facto with our team, not de jure.

  4. Arlo Carreon

    +100 Our intra-team code review relies heavily on branch-based pull requests (on github). I am looking forward to moving our repos to BB, but hard to without this feature in place.

  5. Anonymous

    I received an email from support saying that they are currently working on this issue. Why don't you ask what the timeline is before your team moves?

  6. Log in to comment