Detach Fork from Upstream Repository

Issue #13645 open
Toby Kahan created an issue

I would like to detach or break a fork relationship. We have a repository which was originally forked from another, but now they are completely different code bases.

Originally from this post.

Comments (56)

  1. Magnus White

    This would be extremely useful.

    We are currently stuck with a child repo with a non-existent parent repo (it was deleted). As a result when making pull requests the default target repo is the parent due to it being listed alphabetically. If the pull request is made to the parent a 404 is returned resulting in the pull request having to be remade. This affects our process flows and causes unnecessary grief.

    The repo is also now stuck with the permission settings of the parent with no way to modify them as the parent does not exist.

    It is understandable that detaching the child should be permitted if you can administer both repos. This will ensure the privacy settings are respected.

  2. Clint Tyler

    I was having the same issue but upon deletion of the original repository, the fork link appears to have been destroyed.

  3. Marko Mihovilić

    We have the same issue. The repo was a fork at first but now is a completly different repo. All the pull requests that we create initially want to merge into the original repo which is really annoying since bitbucket tries to generate this massive diff for the pullreq before one switches the target to the new repo and the diff becomes normal...

  4. Alastair Wilkes staff
    • changed status to open

    Hi y'all,

    If there's no intention to ever merge the fork back to its parent, we 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.


  5. Marko Mihovilić

    That would mean that we would (after cloning) have to first delete the repo (before creating a fresh one to push into) which would also delete all issues, pull requests and settings (access permissions etc.)?

  6. Carol Cheng

    For the existing forked repo, is there a way to detach the link? We did not realize that we cannot remove the link between the parent repo and the forked repo.

  7. Gilles Hartog

    this feature seems very useful to me also.

    and from an implementation point of view shouldnt be so hard to realise, right?

    In the background it could simply be as mentioned before, make a copy of the repo, delete project/repo, reinitialize project with same name and copy repo contents back into it, or something like that.

  8. Stresing, Stephan

    We're interested in this feature as well. And we'd like to go a bit further: detach fork from one repo and attach it to another upstream. Our use case: for different projects for one piece of software we work in different cycles. Therefore we have fork nr1 to produce artifact nr1 and we forked from there for producing artifact nr2. Now we contributed fork nr1 back to the upstream and deactivated fork nr1 (not yet removed) and we'd like to attach fork nr2 now to the original upstream (main repo).

  9. David Wright

    I'd just like the repo that was forked to not be the default choice in a pull request. I'd like the master of the new repo to be the default.

  10. Patrick Decat

    I'd just like the repo that was forked to not be the default choice in a pull request. I'd like the master of the new repo to be the default.

    That would be great to avoid mistakes!

  11. Waitbusters LLC

    I have the same issue and would like the feature as well. I'd just like the repo that was forked to not be the default choice in a pull request. I'd like the master of the new repo to be the default.

  12. Arnaud Potier

    Same story here, we have a forked repo that has diverged from its original one, and would like to detach it. We want this feature too!

  13. ソジョンジュ

    When create Pull Request, I change target repository every time. This is so inconvenience.

  14. Shawn Talbot

    This wastes so much time due to mistakes. Having to re-do pull requests is my number one annoyance with Bitbucket!
    It seems if you would give some needed priority to issue #9368 then at least there would be a good enough path to go forward. I would be fine with just #9368 being completed (and it is one of the highest voted issues)

  15. Steven Stanton

    If detaching is not a possibility, it would be good to be able to set the default repo that pull-requests get made to instead. I use Bitbucket Linky with JetBrains IDEs and it always defaults to the parent repo, when I would prefer it to default to the child repo.

  16. Ant Gardiner

    +1 here too. When we create a PR url at the command line even though we specify the correct dest repo it keeps defaulting to the forked repo.

  17. Matt Fisher


    I consider it unreasonable that those of us who have made this "mistake" are expected to delete and recreate our repositories, throwing the whole issue database, pull request history, and all comments in the garbage -- just to avoid the mistakes and wasted time that the interface encourages as a penalty for using a feature in the way it is supposed to be used?

    A fork is a copy of a repository and that is all. I've never understood "fork" to imply a permanent and forced relationship to the upstream.

    Here's Github's definition of a Fork:

    A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project.

    Most commonly, forks are used to either propose changes to someone else's project or to use someone else's project as a starting point for your own idea.

    Bitbucket's definition of fork kind of agrees and kind of disagrees. Yes, a fork is a clone, but it's only for contributing to the upstream repo apparently:

    To fork is just another way of saying clone. Bitbucket Cloud manages the relationship between the original repository and the fork for you.

    Is it a clone or a permanent, inescapable, managed relationship? The implementation is more like conjoined siblings, not a "clone".

    Unfortunately, Github behaves the same way as Bitbucket and forces PRs to default to the upstream with no option to break the relationship in the GUI. But GitHub will do it for you (quickly) if you submit a support request. It's even advertised in their documentation!!! (CTRL+F detach). I couldn't find anything about detaching fork relationships in Atlassian's docs. In fact, I have found many posts from Atlassian staff stating that the only way to do this is to throw away all of your repository's issues and comments by deleting and recreating the repo! ( On detaching a fork: "this is actually not possible"!!

    I'm submitting a support request to Bitbucket to fix my team's affected repos and I'll post back the results. Hopefully the idea that this is "not possible" is untrue.

  18. Tom Redstone

    It isn't a solution, but I believe renaming your old repository, and creating a new one with the original name will work just fine, and won't destroy your coments and pull request history, just leave it orphaned on an old repository.
    Not great, but better than destroying it.

  19. Matt Fisher

    Better than losing the entire issue/PR/comment history, but you'd still lose the relationship between your in-development code and the issues/PRs/comments. This really should be something BB support can handle, especially given the cost to users if they have to do their own workaround. I opened a request and will post back what happens.

  20. Matt Fisher

    I was able to send a support request with a list of repository URLs and they detached from the upstream for me. 🎊

    I requested that they update the documentation to show the process like Github has done. I think that's the most we can ask for while this feature is still in progress.

  21. Samarth Mathur


    I forked because bitbucket preserves more than just the git repository in the fork, also suggests the same user permissions etc.

  22. Sergei Bril

    We need this feature too. I was looking for Copy button in UI, but there is only option to Fork repo. I thought it just copies it, but there is much hardcoded logic under hood we can't control all disable.

  23. saleem

    We have one repository and on top of it we don't have admin ownership.

    I have created fork repo from the original repository and now I have full ownership of new repository.
    our team will commit the code into new repo which is created as a fork with a different name.

    will I face any issue in the future? or it is a good option?

    Need this feature +1

  24. George Pantazes

    It really seems like detaching should be possible, since the Pull Request flow keeps pointing back to the original's master and not the fork's master branch. It's somewhat annoying.

  25. Ryan Tanay

    Seconding @kaytonp, you can put in a support request and they'll detach it from the fork for you. Really should be a thing you can do yourself though.

  26. Stephen Rozner

    +1 to allow using the fork (Origin) as the default for a Pull Request, not the initial forked (Upstream).

    In our case we have two iOS applications that share 95% of the 'code' base, but will soon have almost completely different UI and layout resources. We have to be able to work on them separately, and certainly wanted separate repositories with their own Master branches. The purpose of the Fork is to allow 'code' to be merged/cherrypicked back and forth to avoid duplicate development, so I don't want to detach the fork and lose the Upstream merge capability.

    I will continue to deal with this upsetting Origin default for the pull requests, but with all the settings you have it would be very nice just to have a new Pull Request Setting to set the default repository.

    I also think the documentation was absolutely unclear about this. I might have thought twice about the fork if I knew this was going to happen, but this one setting would likely make forks much more useful for a bunch of people responding to this thread (and likely many more that see this and just turn away seething).

  27. Charlie Hayes

    Stephen: You might consider a library for the shared code. There's also a pretty easy workaround for getting the fork disconnected; create a new repo in bitbucket; on the first screen theres an import option; you can specify to import from the fork repo. You can still merge across using different git remotes like before since the hashes will all align. It's still kinda sloppy.

  28. Stephen Rozner

    Would be tough if not impossible to to share much of the code in a shared library. The view controllers in iOS projects are directly tied to the view layouts in storyboards. A lot of code is in these the controllers, so the need to separate based on the storyboards is the problem.

    Granted I could try to make the view controllers super light and rely on shared library code, but that is a level of abstraction that would make a lot of the visual code more difficult to read. I am sure people can point out MVC and the myriad of of other mechanisms that may help, but most of the duplication will still be at all levels below the view (storyboard).

    I will be making a shared library for some code. It may be that merging between detached repositories will be fine.

    In any case, I still +1 that this should be much more visible in the documentation.

  29. Former user Account Deleted

    Yeah I know its just a shame that we still encounter this issue and there is no fix even with all that people that requested it.

  30. Hayden Crocker

    @awbb - Any update on this? Ought to be quite an easy fix, plus there is a clear and ongoing demand for it

  31. Simen A. W. Olsen

    Here, here! I'll probably move my child repository to a new repository, but it's an issue that we have to do that...

  32. Ashley Kitson

    +1. This is a real blocker to managing standardized repos across a large portfolio. If nothing else, give us a button to unlink fork from parent at least.

  33. Omar

    +1 this could prevent confussions for some use cases. Example: when someone does a PR the parent repository is set and it could do the PR to the wrong repository.

  34. Log in to comment