When creating a Pull Request in a Fork repository the default target branch is from the original repository

[silmarx]

When creating a Pull Request in a Fork repository the default target branch is from the original repository.

Example:

I have a repository "main-repo" with "master" and "feature1" branches.

I forked this repository into "repo-fork-1".

If I go to the "feature1" branch in the "repo-fork-1" and enter in the "compare" view, it shows the diff between this branch (as source) and the "master" branch in original repository "main-repo" (as target). If I press then "Create Pull Request", the Pull Request is created in the target repository.

Even I can change this before creating the Pull Request, one can easily create the Pull Request for the wrong target branch (i.e., the same branch name but in the wrong repository), since it's not expected that it will choose the original repository as default. In my opinion this is wrong.

Is there already an issue opened for this?

[Charlie Hayes]

Our team has run into this problem twice within the last few days. We would love for control over this.

[Keith Ealanta]

Yep, my team too.  Someone will make a mistake at some point.

[Chris Ward]

I just experienced this myself and was confused as to how my PR was created in the original repo, thinking I had somehow misconfigured the fork.. 

[Edgard Zavarezzi]

Same here. Easy to commit mistakes. My company uses forks as a means to start new projects from template projects. This behavior is generating a lot of confusion when creating PRs.

[Simon Byholm, TKE]

Same problem here, I would like to fork from a template repository, but then pull requests are made to the template repository by default.

[Joshua Kaldon]

Our team mistakenly forked several of our template repos not knowing that this workflow would create such chaos.  While this behavior might be "by design", it would be very helpful to many of us if there were some text present during the process of creating a fork that points out how the resulting repository is supposed to be used.  

On that note, is there any way to reconfigure these existing repos to work like normal repos?  Or do I have to delete the repos and re-push the code?  Will it retain my commit history when I do this?

[Charlie Hayes]

1. Rename the old repo to like 'myrepo_forked'
2. Create a new repo with the original name 'myrepo'
3. During the create wizard there's an import option, use the 'myrepo_forked' as the source of the import
4. There's a screwy permissions box; it's your bitbucket creds; somehow it can't use your current session. A colleague's Chrome autofilled the username with his full name from like a shipping autofill instead of the saved bitbucket creds so be careful on that one
5. After the import is complete, you can eventually delete 'myrepo_forked'

[Joe Lee-Moyet]

@Roger Barnes my team is experiencing the same problem - our use case is that we have a template / scaffolding project that gets forked whenever a new project is created to save on a lot of boilerplate in initial development. Now any PRs created on the forked projects default to targeting the template project, which is not what we want. Is there any way to change this behaviour in an existing project?

[Vitalii Saienko]

The same thing. We have a template and creating forks for new projects. Any updates on that, guys?

[Roger Barnes]

Forks are designed for a specific purpose and not intended for seeding new, unrelated repositories. As such, they don't and won't work that way by default.

Project level settings are now available in Bitbucket Server (from 5.2) so you can create a regular repository within a project that inherits settings.

If it is repository content that you wish to use as a template, I suggest cloning and pushing the contents to a regular repository, or using an add-on such as: https://marketplace.atlassian.com/plugins/ch.mibex.stash.templates/server/overview

[Deleted user]

When can we create pull requests with _NOT_ forks?

[kentwong]

Has this been fixed? Can we control this at all?

[silmarx]

You're right. I was creating Pull Requests on a Fork repository because I was doing tests. In a real scenario this should not be a problem. Thanks for the explanation.

[Roger Barnes]

Hi Silvestre, Forks are commonly used as a means for contributing changes back to the upstream repository, hence the default of referring back to it. Under what circumstances do you have multiple people collaborating on a single fork where changes end up in the same repository? It seems an unusual situation, or perhaps an unusual use of pull requests.

[k0pernikus]

It may be common but only in your standard open-source workflows. Yet forks are not always used to contribute changes back to upstream within companies.

A lot of companies are using a centralized organization owned repo where people are working on at the same time.

PR are generated via branches created directly on the centralized repo, not forks.

Forks are on the other hand only created for the sole purpose of having a copy of a repository that has to diverge in a different way and should for all purposes be regarded as its own project. They should not even be aware that there is upstream. And changes to these forks should never become part of the parent.

In my use-case, I forked a repo exactly for that reason and was highly confused that the PR target would point to the parent of the fork; esp. since I forked it to the organization namespace. (I would expect the PR to upstream behavior if I created my own fork in my own namespace.)

I am afraid, that in the future some changes intended for the fork will end up in the parent and create chaos there. Currently, I have to always change the target branch in a PR to the fork itself.

My main concern is not the default, but that I am apparently unable to change it. It would be great to be able to change it via a config to where PR should be pointed.

[kentwong]

@Roger Barnes 

Our use case pretty much aligns with what @k0pernikus  mentioned here

[mattias.andersson.2]

We have also the use case mentioned by @k0pernikus. Each fork represents its own distinct project that inherits from upstream, with minimal (if any) contributions back to the upstream repository. In this situation it makes sense to make the default PR target the forked repository.