Deprecation of Forked Repositories Outside the Parent Workspace

[Shipley_ Samuel]

I'm an open source Drupal developer and have been forced to use Bitbucket a few times in the past. Honestly, I'm not sure why people choose it over GitLab or even GitHub for that matter, I assume they must like Jira and think the integration is beneficial to projects. Thankfully, I've not had to use Jira in years! :)

Since Bitbucket chose to kick open source to the curb and suggested we go back to a patch-based workflow, I'll be pushing to move all government projects away from Bitbucket and suggest others look at their competitors as well. This is a perfect reason why it's SO important to prevent vendor lock-in and not become dependent on internal integrations. This will likely end up imploding projects and causing a mass exit from Bitbucket similar to the exit we seen when Microsoft bought Github many years ago. 

[Jonathon Woolf]

I have to say, I'm confused.  I use several Bitbucket repositories, but I didn't create any of them and to be honest I've always treated them as something of a black box: as long as they work I don't mess around with them.  Only one of them is showing this warning, I guess because it was forked from another workspace but the others weren't.  I don't have access to that parent workspace and have no idea how I could get it.  

Is there a way to sever the connection between the two and leave this fork right where it is?  It sounds like there will be a way to do this, but will it be ready before the Feb 26 deadline?  If not, what else can I do to stop the repo from being merged with its parent workspace?  

[Jared]

Perhaps it's been answered already and I've missed it...but I would really love to know what happens in situations like ours where the original workspace has been sunset and is no longer available.

We need clear answers on how this will affect our access.

[Adam Rouman]

Thank you to everyone who has engaged with this post so far. Based on the feedback we have received, I wanted to provide a clear update (also pinned to the top of this post) on what is happening with forked repositories to other workspaces:

1. This post/update only applies to cross workspace forked repositories. Forked repositories within the same workspace are not affected by this. We will be updating this message in product to only show on cross workspace forked repositories only.
2. Atlassian will NOT be moving any forked repositories into the parent workspace on your behalf. Because of the security and reliability updates we are making to our platform, we plan to, however, automatically break the forked repository relationships. Once forked repository relationships are broken, all pull request functionality will remain as normal/expected.
   1. Please note: Cross-workspace PRs that have already been created will be able to be viewed and merged. You will not be able to create a cross-workspace PR from the fork to the parent if the relationship is broken, but will be able to continue creating PRs from child to parent if both repositories exist in the same workspace.
3. The above change will occur On July 1, 2026. On this date, we will also be removing the ability to create new cross workspace forks. We previously communicated this would be removed February 27, 2026, but are now extending this to July 1, 2026. We want to give enough time to manage outstanding forks and update your software development workflows as needed.
4. If you would like to break the forked repository relationship to the parent repository, you can do so today by contacting support. If you are a repository admin and would like to do this yourself, we are building a self-serve feature to support this. The feature will be available soon and I will update this post again once available.
5. What does this mean for support for our open source workflows?
   • Public repositories remain available – your open source projects can continue to be public, cloned, and browsed as before.
   • For ongoing open source collaboration in Bitbucket Cloud, we recommend:
   • Hosting the project in a designated shared/open source workspace, and
   • Granting trusted maintainers and frequent contributors write access so they can use branches + pull requests within that same workspace, or forks that also stay within that workspace.
   • Occasional or “drive‑by” contributors who cannot be granted write access can:
   • Continue to clone your public repository and share changes as patches (e.g., via git format-patch), or
   • Work with your maintainers to agree on a contribution process that fits your project’s governance (for example, using a shared workspace for community maintainers).

Again, thank you for your feedback and please reach out if you have additional questions.

[ccenvcvb]

When will the update 1. be done ? We're getting needless internal support question if the way we currently working will still work in the future.
In general also keep track of who has seen such messages instead of keeping them endlessly on tha pages of users who already read the message

[Friedrich Müller]

@Adam Rouman 

Hello,

I also can report that for our projects that has many external contributions this plans would make open source contributions annoying und cumbersome. 

I kindly ask you to reconsider your plans. There must surely be a solution that is satisfactory for everyone.
For example, the functionality you want to deprecate could be disabled by default and configured by project administrators via the project settings — determining whether forks are allowed and whether they are linked to the parent repository, for instance for the purpose of creating pull requests.

(Your suggestions for just adding new users with write acess or go back to cumversome git patch files doesnt sound like a good workflow for many current bitbucket user in my opinion)

I also didn't understand your argument why you want these changes?

Why we’re making this change:
This change positions Bitbucket Cloud to offer greater product reliability and introduce highly requested enterprise-grade controls like data residency.

We know that this will be a significant change for some of our customers, especially the open source community. While forks aren’t core to every Bitbucket customer’s workflow, we recognize that retiring open-source pull request support will be felt by those who depend on it.

Can you please make an example? If a project want these settings than it should be able to configure it? Or are there technical barriers?

Best regards,

[Nathan Phillip Brink]

@Friedrich Müller I am reading into the “data residency” to guess that there are technical barriers.

Atlassian probably has all repositories in a single global database and shared storage bin right now. Within this single database they can create new internal repository IDs that are guaranteed unique. They can also query the database and get back information about the parent of a fork. Also, depending on how Bitbucket stores forks, fetching changesets between repositories may be very similar to doing a filesystem-local fetch.

Once they implement “data residency”, they might start partitioning data within the database or actually create separate databases so that a workspace can be designated as being in something like GovCloud or only in US East or only in Tokyo. They will also put the repository object storage in a storage bin which has similar restrictions. Once they do this, they have to treat data from each workspace as if it is a separate database and repository depending on how they query it. And they will not longer be able to do filesystem-local git fetches.

To support forks in this scenario, they would have to perform multiple queries or establish multiple database connections when their current system does not require this. They also have to find a way to fetch commits between different repository git object stores which would end up being more similar to fetching changesets to your local computer than doing a fetch between multiple repositories on one computer. This would add complexity. And if they do add this support, it will make it harder for their system to be accepted by customers who want data residency guarantees because such customers would rather be told that cross workspace/residency forking is technically impossible than that cross workspace/residency forking is controlled by a setting.

[smu_sc_gj]

@Adam Rouman as an academic I've been providing template projects for students via Bitbucket for over a decade.  I really don't want all those forks back in my workspace!

If students can no longer fork my base code into their own workspace, Bitbucket no longer works for me.