Subgroups in Gitea

[ulm0]

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/

[gayprogrammer]

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

[bkcsoft]

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 🙂 )

[bkcsoft]

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

[gayprogrammer]

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 🙁

• 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?

[bkcsoft]

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

[bkcsoft]

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

[ghost]

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.

[tomdavidson]

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.

[Th3Whit3Wolf]

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

[lunny]

@Th3Whit3Wolf No people are working on this.

[lakostin]

Still no update?

[6543]

dont see any

[Nicolab]

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?

[lafriks]

It is planed but nobody does work on this currently

[Nicolab]

Ok thanks for the confirmation

[cwchristerw]

Currently this feature is already available in Github

[Asherslab]

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

[lafriks]

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

[tomdavidson]

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?

[bjeanes]

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.

[Nicolab]

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

[atommaki]

I've just finished a gitea trial for our company which failed on this issue. I believe gitea is one of the best git hosting solution, but without this capability it is just not enterprise ready. If you have dozens of git repositories and different user groups than it is a nightmare to manage all on the same level. For my boss: that was a no go. Now I am stuck with gitlab, what is an ugly monster compared with gitea (at least from the administration point of view).

ps: This issue is currently the 5th most liked (I assume that meant 5th most requested) amongst 1800+ (!) open issues...

[mrexodia]

I've just finished a gitea trial for our company which failed on this issue. I believe gitea is one of the best git hosting solution, but without this capability it is just not enterprise ready. If you have dozens of git repositories and different user groups than it is a nightmare to manage all on the same level. For my boss: that was a no go. Now I am stuck with gitlab, what is an ugly monster compared with gitea (at least from the administration point of view).

ps: This issue is currently the 5th most liked (I assume that meant 5th most requested) amongst 1800+ (!) open issues...

Perhaps you could convince your employer to contribute some manpower to Hacktoberfest and help implement it…

[tomdavidson]

@atommaki Im one to have liked subgroups but this position of subgroups being deal break seams both anomalous and hyperbole, ie, not productive. GitHub is not suitable for your company either? Subgroups being the deal breaker seems anomalous.

GitHub has over 200 million repos, used by 73 million developers with 32 million visits per month. The lack of subgroups has not impeded use and adoption. I couldnt find an org count but have worked at places with over 1000 repos and regularly see orgs with dozens and they have not left for GitLab's subgroups.

As VP of Eng that finally go my way and purchased GitLab, I was pissed to run into bugs for Enterprise features that were over 2 years old and waiting for community contribs. I ended up getting the contact cancel, money back, and moved to GitHub where thinks actually work. GitLab's open core model is a lie, the worse of both worlds where the community is exploited and the company focuses on royalty extraction. The fact that GitLab has subgroups and GitHub does not is negligible.

If dozens of repos with various user groups is too much to admin, I dont understand how managing GitLab with subgroups makes that big of difference. Yes a subgroup can be configured to inherit some settings from the parent group but its still massive amount of point and click admin.

You can use terraform/pulumi, a github app, or even crossplane to manage your github and gitlab config. Perhaps the administration experience and functionality is where Gitea should focus? Build-in a configure all the settings by in repo config file?

Im also a fan of shared repos for each service boundary or bounded context so a team typically only deals with one repo. You end up with some monorepo cicd config addressing separate workspaces but your business might only have 10 bounded contexts and dozens is unlikely. I dont see massive value difference in subgroups vs a shared repo, at least not enough to put up with GitLab's business model.

[atommaki]

@mrexodia

Perhaps you could convince your employer to contribute some manpower to Hacktoberfest and help implement it…

My company goes with gitlab now and not interested in another migration, so they motivation is low. However I am happy to help. Write me a pm and let's have a call...

[atommaki]

@tomdavidson Github has subgroups, but it works bit differently, as soon as you register you have your "domain" of repositories and access management. But anyway, regardless how github works, a tree based structure is usually very natural for a company, it helps not only with the permissions, but gives you a good overview of what repositories you have and it likely mirroring some way the structure of the organization. And as it quite obvious from this thread I am not the only one thinking like this. This feature is missed by many.

[goyalyashpal]

wow lol. this argument is just so awesome. i really really like this. P.S: same can be said for the lack of FOSS model of github. so, why bother with creating yet another Forge site. the point should be improving upon, and not just copy pasting some other popular existing service. lack of sub-groups is a deal breaker for those who have used the subgroups even once, the same way non-FOSS becomes a deal breaker for people who start to enjoy FOSS even once. Tom Davidson wrote:

…

@atommaki <https://github.com/atommaki> Subgroups being the deal breaker seems anomalous. GitHub has over 200 million repos, used by 73 million developers with 32 million visits per month. The lack of subgroups has not impeded use and adoption.

[lafriks]

Let's stay to the topic, this is not place for discussion. If you have nothing to add that would contribute to implementing this feature in Gitea, just add reaction to issue. Otherwise if you want to see this issue fixed you will have to wait, implement yourself or pay someone to implement this for you.

[mygit123hotmail]

1.21 Will it be implemented? Very good. Multifunctional

[lunny]

1.21 Will it be implemented? Very good. Multifunctional

Why do you think that? Nobody are working on this.

[delvh]

To clarify @lunny's words:
Gitea is (almost solely) developed by volunteers in their free time.
If you want a (large) feature and no one is working on it yet, you need to implement it yourself to see any chance of it getting merged.
Otherwise, it is fairly unlikely that a feature as big as that will ever be merged.
(One exception: if a maintainer misses this feature enough to go through the work of implementing it for you)
There are 2000 issues here (at the time of writing). We are already swamped with what needs to be done.

However, if you were to implement it, here's a word of advice:
Discuss your proposed solution in detail here.
The description of what this issue entails is completely missing at the moment, as far as I can see.
Otherwise, it can happen that you develop something whose architecture is absolutely not suited for Gitea.

[VAllens]

That's necessary.

[KarenArzumanyan]

It would be great. We also suffer from the lack of such an opportunity. We are really waiting for someone to take up the implementation.
With great hope.
Thank you.

[Nicolab]

Yes it would be great... But since 2017, I no longer believe.
Go ahead, unsubscribed from this issue and I have migrated my personnal repos.

Good luck

[meng-plus]

Can this function be easily implemented? For example, identifying the "/" in the warehouse name as a subdirectory also facilitates our management of internal warehouses within the organization
Just like when we name our branch "feature/mod1", we get a feature group
I believe that this change can also solve most of the requirements without the need to change how to modify the permissions of the subgroup

[wxiaoguang]

I could understand many users really like this feature and I also like it, however, by my understanding, it is nearly impossible to implement it at the moment. There are too many blockers for it.

[atommaki]

.... it is nearly impossible to implement it at the moment. There are too many blockers for it.

So the work could start by making a list of these blocking issues.

[HyCore]

8 years it has been. Can we setup a bounty for that feature ?
(also making this alone doesn't seems possible, it has to be a team work)