When we create pull requests, the default repo is the parent repo from which we are forked from.
i.e. Repo A, and Repo B is a fork of A.
I create a pull request in Repo B, it sets up a default PR aimed at Repo A. The description field contains a diff between the two repositories (which you can imagine is a massive list) and this opens up opportunities for mistakes.
I don't see any options within Bitbucket to change the target.
I subscribe to the sentiments expressed so far. In our case the rationale for using a fork is that we can occassionally sync changes from upstream into origin (and vice-versa). This is however by far less common than updating the actual fork itself. I don't see any problems with this kind of triangular workflow. In a big team this is a major hurdle since every new developer will have to get used to the routine of switching the default merge target. Why can't this be an option?
I really don't understand the rationale behind the bitbucket choice. The way everybody here describes using forks is also the way I would use them, and also the way github and gitlab use them iirc. I don't understand in what world it is useful to have RepoB forked from RepoA, and then make a new branch on RepoB but merge that into RepoA by default. If I want to merge something in RepoA, I would just make the branch there, not go through the trouble of making a fork into RepoB first. Especially because it's the default option, telling all developers that for every PR, they first need to make sure they select the right repository, is asking for someone to forget and b0rk a full repo at some point.
We use the fork workflow as well for a lot of our projects. We want to be able to get the changes from Repo A (main) back to Repo B (fork), so that's why a fork is useful.
However the changes we make in Repo B are always related to Repo B specifically. The PR's for Repo B should therefore always go to Repo B.
Besides the big list in the description of the PR it also slows down the PR page massively. I imagine this is because it tries to compute the changes between B and A (which is a lot). And because the page becomes so slow it's difficult to switch the target repository as the interface is very unresponsive for several seconds.
If you forget to change the target repository quickly you are basically stuck until the diff between B and A is computed and the interface becomes (somewhat) responsive again.
Having the default target repository be Repo B would resolve this issue. Another solution would be, as Kentwong suggests, that you are able to set the default target repository, just like you can set the default target branch.
In this tutorial, in the first screenshot you can see that there is a dropdown for the target branch: https://support.atlassian.com/bitbucket-cloud/docs/create-a-pull-request-to-merge-your-change/
After you change the target branch, the diff will update.
No, my issue is the default target repository. I've created an imaginary pull request diagram.
Our Repository is called "thisrepo", and it was forked from "parent_repo". When we open a PR from "thisrepo", the default target repository is "parent_repo" which we do not want.
I've looked in Advanced settings and I only see an option for default target branch, which does not seem to affect the default target repository.
Does your repository need to be a fork? If you are not using the forking workflow, then you could clone the original repository (instead of forking it) and the default destination branch for pull requests would be the cloned copy rather than the original that was forked.
Hey Community! We’re willing to wager that quite a few of you not only use Bitbucket, but administer it too. Our team is excited to share that we’ll be releasing improvements throughout this month of...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events