Gitea: Gitea: Group repositories under a directory

[vignesh-rajendran]

Dear Gitea team,
Is there any way to group repositories under a directory instead of hosting all the repositories at TOP of an organization?
Any help would be really appreciated.

Thanks and Regards,
Vignesh Rajendran

[lunny]

Maybe we could use topic to do that?

[bkcsoft]

You mean like sub-groups or topics?
Subgroups: https://github.com/go-gitea/gitea/issues/1872
Org/Project/Repo proposal: https://github.com/go-gitea/gitea/issues/363
Repo Topics: https://github.com/go-gitea/gitea/issues/219

[belliash]

Any chance to get this implemented? :+1:

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because of inactivity. You can re-open it if needed.

[belliash]

Please implement this.

[typeless]

I want this feature too. But there are still many unclear details about how this would be implemented.

Reminder: https://github.com/go-gitea/gitea/pull/3711/files?file-filters%5B%5D=#diff-d4e2553a87eb8b329efd7335f028903c

[typeless]

FWIW, Google has it that is very close to what I want https://android.googlesource.com/.

[typeless]

Just a brief note.

There are two simple approaches. The first is to allow the Name of models.Repository to contain slashes(/).
The second is to add a new field Namespace to models.Repository.

If we allow slashes in Repository.Name, I imgine that most of the code can be backward-compatible and remain unchanged with the old behivior. And user would not notice the difference when they do not have repositories with slashes.

To emulate the appearance of hierarchical directories, we can filter the repo names with the prefix path when a repo list has to be generated.

The git command can still use the Repository.Name verbatim along with how models.RepoPath currently works.

What remains to be clarified is how to distinguish a repository path from an endpoint when routing requests.
it's unclear how we should resolve the clashed names of a path and a repository too.
Say /a/b/c where c can be a URL path to view the repositories under the directory c or a repository named c under /a/b/.

I think the second approach (with an extra Namespace field) is harder to implement.
It can probably provide more flexibility which I can not clearly envision.

[lafriks]

@typeless allowing / in Name would not work as current routing does not allow that so it will simply not work

[lunny]

Another proposal is a repository could be a group /:org/<:groupname or :reponame>. When it's a group, we will list the group's repositories. The change is small and keep compatible with old version. The permission to a group will be applied to all the repositories on this group.

[typeless]

@lafriks yes, that is a part that requires effort. Hopefully, the ambiguity can be revolved given some supported rules of Macaron. Needs more investigations.

@lunny That sounds good. But I need it to support nested groups as well.
That permission-to-group thing seems to be useful too.
It's also desirable if we can map the group hierarchy to the local locations of the git repositories respectively (each group corresponds to a filesystem directory).

[lunny]

Did you mean subgroup of a group. That sounds complicated.

[typeless]

@lunny Yes.
I agree it would be complicated. Part of the reasons is that hierarchical structures are not very suitable for a relational database.
So, encoding the namespace information into repo names seems to be good enough. And that is how Gitiles (and probably Gitweb) works too.
It would make search operation be O(n). But I suppose that wouldn't be a big deal because we aren't going to handle millions of repositories.

[lunny]

@typeless No. Gitea.com will. :)

[typeless]

@lunny 😆
That is alright. Searching repositories by name, which is string comparisons by itself, is already O(n). Naming it with slashes or not wouldn't be different, I assume.

[typeless]

We would have to introduce a new arrangement of URL routes to avoid the ambiguity related to the repo names. Say, a separator to distinguish the repo name part and the rest.

By the way, slashes should be acceptable in branch names (by vanilla git) too. It appears that branch names are always at the end of the URLs.

[lafriks]

@typeless problem is that in current routing you can't have two wildcard arguments

[typeless]

@lafriks I see. You are absolutely right. So, I am thinking about something like /org/a/repo/path/~commits or /org/a/repo/path/~/commits, where ~ acts as a marker to distinguish endpoints from repo names. I don't know if there is a conventional way of dealing with such a situation.

Regarding routing, it could be making an enhancement to Macaron or migrating to other routers. But at the very first, we have to figure out how to make the paths unambiguous (or if possible at all).

Addendum: by 'umambiguous', I mean whether it's possible to make the routing rules codifiable in an acceptable complexity.