How to list/get all the fork of a bitbucket repository?

[Rikki Vizcarra]

Hello,

I've been trying to find a way to list or get all the fork of a given bitbucket repository.  Is there such a thing in bitbucket?  I know a forked repo can see the parent repo, but I want the vice-versa.  From the parent repo, I want to list all forked repos.

[Daniil Penkin · Accepted solution]

Hello @Rikki Vizcarra ,

Welcome to the Community.

Sure, forks info is on the Repository details card in the right sidebar:

Hope this helps.

Cheers,
Daniil

[Rikki Vizcarra]

Hi @Daniil Penkin 

My issue is that it says zero from our main repository as an admin, which is weird.  But accessing it as member who forked the repository, it shows the list of forks.

See screenshots below..

First below is the screenshot from the Admin account accessing the main/parent repo.

Second screenshot, is accessing the repo from a member that had previously forked the main/parent repo.

What we need is from the parent account, we can see the list of forked repos.

[Rikki Vizcarra]

Hi @Daniil Penkin 

Is this a bug or is this how it really works in bitbucket?

[Daniil Penkin]

Sorry I didn't have time to get back to your question yesterday.

I believe it's caused not by a bug but by the visibility settings of the forks.

When you fork a repository, you have an option to make that new repository private. Moreover, admin of the repo can force any forks to be private (there's a setting under repository preferences). Now, a fork is included into that number on the side card to a user that looks at it only if the user has at least read access to the fork. As in, if the fork is private, only owner of the fork repo will see their repo in the fork list.

So I believe the admin of the original repository doesn't have access to the fork created by the person who took the second screenshot, so admin see 0 there. While the person who forked the repo obviously has access to the fork, so they see 1.

Does this make sense?

However if admin of the original repo has access to the created fork but still has 0 in that side card, this is not expected and must be a bug.

Let me know if that's the case.

Cheers,
Daniil

[Rikki Vizcarra]

Thanks @Daniil Penkin thanks for the explanation.  I do get it, it's just that I can't remember having the same issue with github.

So for PRIVATE based repos...

I hope that there will be a feature someday, if possible to at least see how many has forked the parent repo.

Or better yet, a feature (optional of course) that when forking a repo, the admins of the repo or at least the owner can be set to have read access to the forked repo.  Of course there is a notification to whoever is forking it that the owner of the parent repo will have a read access to their copy.  Honestly, as long as the parent repo can see the count and who forked them is a great feature, not necessarily have access to the forked repo.

Another way also, would be that the forked repo can have the same copy of people who have access to the parent repo, but all with read access to it.

Anyway, we have made workarounds based on your explanation. Thanks again @Daniil Penkin 

[Daniil Penkin]

No worries :)

I can't remember having the same issue with github.

I'm not entirely sure how similar functionality is designed in GitHub but I'd be surprised if it listed some private repositories you don't have access to.

I hope that there will be a feature someday, if possible to at least see how many has forked the parent repo.

Yeah this makes sense to me, as in the number could definitely reflect total number of forks including private, while the list would surface that only some of them are listed if that's the case. I'll take this to the team and will let you know about the outcome, ok?

Or better yet, a feature (optional of course) that when forking a repo, the admins of the repo or at least the owner can be set to have read access to the forked repo.

Another way also, would be that the forked repo can have the same copy of people who have access to the parent repo, but all with read access to it.

We actually similar feature request. However, this might contradict to the permissions configured  for a workspace, so it's a big question whether we want to go that way.

So, hopefully we'll soon make some changes to avoid confusion about meaning of that number.

Cheers,
Daniil