Support for multiple forks within same organization.

[SoulSeekkor]

Feature Description

Related to #12021, is it not possible to fork the same repo twice and have the same owner? Is there any technical limitation why this is not possible? I have a previous fork in my personal user as the owner and archived it as I wanted to keep the changes I've made to it, but wanted to create a new fork (temporary) to make further changes and noticed I can't select myself as owner on the new fork?

Screenshots

No response

[holgersson32644]

Even forking in the same namespace (i.e. a username or an organization) doesn't work. There is a funny workaround though: Fork into another namespace and then move the forked repo.
I guess it's just a sanity check somewhere that just shows all possible namespaces but doesn't suggest the current one.

[hayashida-katsutoshi]

Any progress? We need multiple forks within the same organization too. We are a game developer who creates 100 games every year. One engineer develops two to three games every year. All games are forked from a few template games for each game type. Because of this limitation, one engineer can create only one game for his life cycle.

[delvh]

@hayashida-katsutoshi That sounds like you are misusing template repos as forks?
With this field () during the repo creation, you can set a template repo to create your repo from. That does exactly what you want, and is already implemented and has been supported for quite a while.
See also https://docs.gitea.io/en-us/template-repositories/

[vettamatt]

We need this too.

Our use case is a mirror of a Github repo, and we want to fork it for multiple customers.
Template repos definitely don't work for this use case.
For simplicity, we have a customers organisation, and we name repos "customername-reponame".
This avoids having many organisations. It's a usability decision.

[tmnvanderberg]

For us, the template feature is close to doing what we want - but not quite.

The problem: We are using a rebase style for our projects.

However, templating destroys the history.

Forking keeps the history but requires seperate orgs for each fork.

(We have what are essentially hundreds of forks (for different customers) our our base software, sometimes multiple per customer)

So we can only do manual copies of the repositories - but then you lose all the access settings and such.

In my view the solution would be to allow preservation of history (i.e. make squash optional) when using a template repo.