gitea

gitea copied to clipboard

Feature proposal

GitLab 9.0 now allows to create subgroups for groups/organizations, It would be great if we could do the same in Gitea.

• Subgroups Docs: https://docs.gitlab.com/ce/user/group/subgroups/

Does Teams provide some or all of this functionality? What is missing from Teams?

Teams would not provide "endless" nested groups 🙁

In any case, this would require a large rewrite of how we're handling Organizations today (GitLab put a lot of time into Subgroups...) and would not be backwards compatible (hence why Subgroups in GitLab was introduced in a Major release so breaking changes was allowed 🙂 )

And to better answer @razzintown, Teams can't have repositories.

Let me know if my understanding is correct:

Teams can't have repositories.

• Repositories may be assigned to one or more teams.
• Repositories may be set to private to prevent other teams from seeing them.

Teams would not provide "endless" nested groups :slightly_frowning_face:

• Team names may contain a dash to give the appearance of nested groups, i.e. "company-department", "company-department-managers", etc.

Since multiple teams may share a private repo, is there any other functionality missing?

Sub-groups are not only about permissions, but structure as well. Say you have an Orga with a total of 300 repos over 30 teams, there's no way to structure that w/o proper "folders" (sub-groups).

So in the end you end up with orga/team30/repo10 instead of orga/repo300

In any case, this would break a lot of existing stuff and be a major overhaul so I'm setting this for 2.0 for now

This would automatically give us the pastebin/gist feature #693 as well, or any related idea, since some nested names could be reserved for those features like giteaUser/gist or giteaUser/pastebin just off the top of my head, or with a dot prefix if that's legal with git, not sure. It would also allow users to create new repos progamatically with permissions already set by the parent 'space'.

It could also eventually allow federation since it basically boils down to automagic merging, and using mirrors nested in reserved namespace would allow for manual conflict resolution as fallback without polluting the root namespace with lots of mirrors.

We org our git projects into groups of bounded contexts. Where the git repo is, informs the purpose, scope, and communication channels, as well as the authorization to the project. subgorups can be valuable.

Is there any estimable timeline when this could potentially be implemented? This would be super useful.

@Th3Whit3Wolf No people are working on this.

Still no update?

dont see any

I use Gitea for myself and Gitlab for team work. In Gitlab we have subgroups containing a lot of repos. That's what's keeping us from migrating. This possibility in Gitea would be really great. Is this feature is planned?

It is planed but nobody does work on this currently

Ok thanks for the confirmation

Currently this feature is already available in Github

would also love this feature. Our team is migrating from GitLab and this is a feature we sorely miss

I'm planing to work on virtual subgroup functionality that would not affect urls so repository names would still need to be unique but it would allow grouping repos in subgroups

I dig how GitLab groups can be used for access control - would the virtual subgroups be similarly used? ... and I like the namespace. For example, I'd like parent Gitea groups for bounded contexts. Each context could have subgroups based on convention as schemata or api or handbook, etc. Having to have unique names would end up with virtual-groupname/groupname-schemata or the like.

GitLab has some troubles sorting out GitLab Pages' domains with subgroups. What makes subgroups difficult with Gitea?

I agree, but I think virtual subgroups without namespaced paths is a good and easy starting point. I support that for sure but would also like to see it go further.

With or without URL path, the important thing is to have some repositories into subgroups.

I agree the url path is not most important and the GitLab implementation is still a bit janky. There is the access control issue but as some have stated, there is also the UX concerns of organizing repos by groups and subgroups.

ABAC systems and advanced content systems both work off of taxonomies. Maybe adding a parent attributes is how @lafriks plans on implementing virtual groups. We could have both access control policies and visual organization based on attributes. Maybe an attribute approach would this would better facilitate organization to structure as we want our software (network of contexts) rather than based on a tree like the HR org chart (conway's law).

Would you like any help with this feature @lafriks?

Another interesting aspect of the way Gitlab subgroups work is that you can use relative git submodules (to access the repositories with both ssh and https and allow exporting offline builds):

https://docs.gitlab.com/ee/ci/git_submodules.html#configure-the-gitmodules-file

Is there a place available to fund this issue?

~You can visit https://www.bountysource.com/teams/gitea~

Has anyone an idea what happened to this feature request?

Even if it was added to the 1.15 roadmap #14477, it wasn't implemented. I also didnt found anything regarding a more fine grained orga/team handling in 1.16 #16429.

We would love to see this feature in gitea.

It's on my individual backlog but have been quite busy lately so it will be done when it's done :D

I was reorganizing my repositories to match my local folder organization and was bugged not to find the create subgroup button (gitlab reflex from my job) :D

I was reorganizing my repositories to match my local folder organization

@seboss666 Genuinely interested in knowing how you "reorganize" repositories...? Do you mean like with APIs? Or do your repos just have code and no issues/PRs/Wiki/etc, so you can just clone and re-upload under a different name?

I was reorganizing my repositories to match my local folder organization

@seboss666 Genuinely interested in knowing how you "reorganize" repositories...? Do you mean like with APIs? Or do your repos just have code and no issues/PRs/Wiki/etc, so you can just clone and re-upload under a different name?

I've split a big bloated repo into multiple ones, and was hoping to "group" them. For now, my repositories are almost all just codes, any "wiki" goes to a dedicated wiki elswhere, and for the rare issues I would like to keep, the "original" repository is still there, just with less far code.