Sensible defaults for Pull Request configuration

Issue #5084 wontfix
Kevin Stanton
created an issue

Before the upgrade to the newer, sexier BitBucket, when creating a pull request it would select sensible defaults. For example, let's say we have:

MainRepo, with 2 branches: default, stage

then I fork MainRepo as MyMainFork.

I make changes in the default branch of MyMainFork, and push them to my fork on BitBucket.

At that point, I select "Pull Request" to issue one. In the old BitBucket, by default it selected the branch w/ changesets that were ahead of the common ancestor between MainRepo and MyMainFork, and it would choose the destination repository as MainRepo.

In the new BitBucket, it picks the default branch and MyMainFork as the defaults for the Pull Request destination. This doesn't make any sense!! Why would I issue a Pull Request from MyMainFork to MyMainFork?

I've done this by accident twice now, and was left wondering why nobody could see my Pull Request.

Comments (24)

  1. Marcus Bertrand staff

    The way it works is that we default as follows:

    The most recently updated branch in the current repository is selected by default and the default or master branch of the same repo is selected as the destination.

    If you are working in a fork, the usual workflow is that you'll be merging from your master/default into the fork. If the master/default is the last updated, we'll default from your master to the parent of the fork.

  2. Mike Macaulay

    Marcus,

    Is there any way to change these defaults? We're in the situation where we've gone so far away from our forked repo that our project is really stand-alone.

    Alternatively, since we're so far away from the original, is there a way to remove the relationship of our project to the forked project so that the pull request button won't default to the forked repo? I've tried looking at git remote but the forked repo is not in that list.

    Any help would be greatly appreciated!

  3. Laurent Royer

    This is indeed terrible UX. Our team can't handle the risky burden of "change the repo, or else your PR will go in limbo" so we eventually decided to delete the legacy repo. Sad :(

  4. Mikhail B

    Absolutely agree with everyone - this is poor UX. Our team has done this by mistake at least a few times. Also, it doesn't 'default' to repo that was most recently updated. It always defaults to 'parent' of the fork. +1

  5. Michael Fleet

    If you are working in a fork, the usual workflow is that you'll be merging from your master/default into the fork. If the master/default is the last updated, we'll default from your master to the parent of the fork.

    This is completely inaccurate for teams using the "gitflow" workflow. Our "usual workflow" is to create PRs for every feature branch, to be merged into the current fork we're working from. Upstream PRs are a totally different animal.

    Please, Atlassian staff, reconsider this woefully inaccurate assumption. My team is seriously considering other tools because Bitbucket's easy-to-fix-yet-terrible-miss in this area is causing far too much confusion.

  6. Robert Durgin

    +1 this is constantly an issue for us when developers keep accidentally merging into the parent fork. Wish there was a setting to set the default parent or fork + branch combo to merge into in a PR.

  7. Nagendra Rao

    Maybe make the default a config item for the account admin? Let them decide what default works for their team? Com'on BitBucket, you can't just ignore all of us.

  8. Log in to comment