Ability to configure default destination repository for PRs opened from forks

Issue #11270 wontfix
Johan Nilsson created an issue

When you have a new forked (current) repo and you create a pull request that pull request is incorrectly pointing to the original repo and not to the current repo. This is very confusing and it is extremely easy to get it wrong. There is no way to set the default target repo to be the current forked repo instead of the original repo. (I have searched for a solution and asked the support too... )

1 - the default should be the current repo not the original repo (bug) 2 - you should be able to set the default repo in the settings (enhancement)

In my case, there is NO intention to ever merge the repos back together again. Dont want to manually have to change this every time in the provided drop down since it is very error prone (easy to forget)

Comments (25)

  1. Zachary Davis Account Deactivated

    Hi Johan,

    If there's no intention to ever merge the fork back to its parent, I would suggest cloning the repo and pushing it back up as a new repo. Then there will be no actual link (from Bitbucket's standpoint) between the parent and the "fork". If you fork a repo, Bitbucket assumes it's being forked in order to contribute back to the parent.

    I'll still raise your request to make it configurable, but I wanted to note that there's an easy workaround.

    Cheers, Zach

  2. Danny Gehl

    We have a similar issue here, we want the repositories to be connected for eventual merges which can happen from time to time but the default use case would be that development happens in the forks and currently developers have to update the target all the time and if it gets missed the change is incorrectly merged into the upstream which is confusing and creates unnecessary extra work.

  3. Miguel Bazzano

    I would like to +1 this since we also have a similar case. In our case the fork will probably become the new master, similar to Danny Gehl case.

  4. Łukasz Roszak

    +1 As if we have a framework project and production projects forked from them it is almost always a review pull request back to our master.

  5. Greg Barker

    Why would you fork a repository to PR into a different repository? This seems like an oversight. The default PR-to branch should be the repository in which you're creating the PR.

  6. Duncan Lundie

    Surely the default repository for pull requests should be the repository containing the merge candidate?

  7. Simon Monette

    We also ran into that issue.
    Its kind of awkward while working in the fork having to change the PR destination to the local fork develop branch instead of the original repo develop branch.
    Syncing the fork to the original repo is done fewer times then internal PR, changing the default destination should be supported.

  8. Tim Wheelock

    +1 everyone above, I guess this has been open for 3 years. Any chance Bitbucket will make this change? It seems like a no-brainer, that this should be configurable...

  9. Cordell Barron

    I too would like this. In our case we purposely forked to diverge codebases and wish to kepp the history in both cases so opted for this over creating a new repo with the state of the original repo. If a repo is forked, It would be nice to retain control of which repos are tracked upstream (choosing not to track the original remote if desired), and the default should be the repo that you branched from imo.

  10. Alastair Wilkes staff

    Hi everyone,

    Given the relative lack of discussion on this issue in recent years, and since the team is currently focused on higher priority items, I am closing this issue to indicate that we don't plan to address this in the near future.

    Thanks,
    Alastair
    Bitbucket PM

  11. Frode Egeland

    Suspecting that the only reason there’s been little discussion recently, is because people who read this thread feel like the Bitbucket team aren’t taking them seriously.

  12. Maciej Szerling

    We need the feature, it’s not implemented, we hoped Bitbucket team can deliver.

    @Alastair Wilkes , what else are we supposed to be discussing here?

  13. Łukasz Roszak

    @Alastair Wilkes There has been no discussion from Bitbucket side. Users have shared their needs, that have not been addressed.

    Have you expected a discussion whether we want a dropdown or a textbox?

  14. Cordell Barron

    I wouldn't even classify this as an enhancement, its a BUG!!! (default git behavior which is not working as expected... it's not something which is 'new' to the git ecosystem). BB has all the information backend, just literally need to have the option frontend? Surely a simply GUI fix?

  15. Martin Devillers (Selectives)

    +1 and I don’t understand why this hasn’t been fixed in the 4 years (!) this has been reported. Defaulting to the origin is non-intuitive and (in my opinion) a bug. Either change the default to the forked repository or give users the ability to change the default target.

  16. Log in to comment