What problem would this solve?
📝 Context & Motivation
Many teams and enterprises adopting Gitea face a common structural bottleneck: the organization structure is completely flat. While Gitea is widely appreciated for its lightweight design and speed, the lack of hierarchical Repo Grouping / Subgroups under organizations makes it difficult to scale for large teams, microservice architectures, or multi-department setups.
This has been a long-standing request within the community (frequently discussed in older threads like Issue #1872 and related feature requests).
❓ Questions for Maintainers & Core Contributors
As the project evolves, we would love to get an update on the current stance and roadmap regarding this feature:
- Current Status: Is there an active RFC, design proposal, or branch working on hierarchical organization groups / subgroups?
- Architectural Roadmap: What are the primary technical blockers preventing this implementation? (e.g., URL routing changes, Git path storage, or permission inheritance models like Team ACLs)?
- Community Contribution: If this is currently unassigned or planned for a later milestone, is the core team open to community contributions or design proposals for this feature? If so, is there an existing preferred architectural direction?
Any insights, updates, or pointers to ongoing discussions would be greatly appreciated by the community!
What do you propose?
To introduce repo grouping with minimal disruption, we propose an incremental database-first approach: introducing a dedicated repo_groups table with self-referencing parent IDs to establish structural foundations. This allows for an initial phase of virtual grouping and dashboard filtering while keeping existing repository routes intact, before gradually layering on hierarchical URL routing and team permission inheritance as the feature matures.
What problem would this solve?
📝 Context & Motivation
Many teams and enterprises adopting Gitea face a common structural bottleneck: the organization structure is completely flat. While Gitea is widely appreciated for its lightweight design and speed, the lack of hierarchical Repo Grouping / Subgroups under organizations makes it difficult to scale for large teams, microservice architectures, or multi-department setups.
This has been a long-standing request within the community (frequently discussed in older threads like Issue #1872 and related feature requests).
❓ Questions for Maintainers & Core Contributors
As the project evolves, we would love to get an update on the current stance and roadmap regarding this feature:
Any insights, updates, or pointers to ongoing discussions would be greatly appreciated by the community!
What do you propose?
To introduce repo grouping with minimal disruption, we propose an incremental database-first approach: introducing a dedicated
repo_groupstable with self-referencing parent IDs to establish structural foundations. This allows for an initial phase of virtual grouping and dashboard filtering while keeping existing repository routes intact, before gradually layering on hierarchical URL routing and team permission inheritance as the feature matures.