[FEAT] Proposal to extend Forgejo URL structure from organisation/repository to organisation/project/repository

aral commented

2023-07-11 13:16:19 +02:00

Personally, I don’t use organisations to represent an organisation but to organise a project that might have multiple repositories.

e.g.,

Project: https://codeberg.org/kitten

Repositories:

On a Forgejo instance like codeberg.org, this does mean polluting the organisation namespace.

It would be a major change but what if we extended the URL structure in Forgejo from:

/organisation/repository

To:

/organisation/project/repository

This would cover 99% (if not 100%) of my use case for “organisations”.

In the example above, I’d then only use one organisation (small-tech) and have everything under that without polluting the global/limited organisation namespace.

e.g.,

This should keep the organisation namespace free while allowing an infinite namespace for projects under which to organise your repositories.

Thoughts? :)

(Moved from Codeberg-e.V./requests#11 (comment))

Personally, I don’t use organisations to represent an organisation but to organise a project that might have multiple repositories. e.g., Project: https://codeberg.org/kitten Repositories: - https://codeberg.org/kitten/app - https://codeberg.org/kitten/wallpapers - https://codeberg.org/kitten/assets - https://codeberg.org/kitten/globals On a Forgejo instance like codeberg.org, this does mean polluting the organisation namespace. It would be a major change but what if we extended the URL structure in Forgejo from: ``` /organisation/repository ``` To: ``` /organisation/project/repository ``` This would cover 99% (if not 100%) of my use case for “organisations”. In the example above, I’d then only use one organisation (small-tech) and have everything under that without polluting the global/limited organisation namespace. e.g., - https://codeberg.org/small-tech/kitten/app - https://codeberg.org/small-tech/kitten/wallpapers - … - https://codeberg.org/small-tech/domain/app - etc. This should keep the organisation namespace free while allowing an infinite namespace for projects under which to organise your repositories. Thoughts? :) (Moved from https://codeberg.org/Codeberg-e.V./requests/pulls/11#issuecomment-979581)

👍 34

aral referenced this issue from Codeberg-e.V./requests

2023-07-11 13:20:16 +02:00

Add username request template #11

Ghost added the

enhancement/feature

label

2023-07-11 14:52:46 +02:00

caesar commented

2023-07-12 01:21:09 +02:00

Member

I quite like this idea, and I think Sourcehut does something similar.

It would have to be optional (at instance level I guess – though maybe it could be at organisation level?)

In cases where an org has a single main repo it might be frustrating to have URLs like
https://codeberg.org/forgejo/forgejo/forgejo/...

I quite like this idea, and I think Sourcehut does something similar. It would have to be optional (at instance level I guess – though maybe it could be at organisation level?) In cases where an org has a single main repo it might be frustrating to have URLs like `https://codeberg.org/forgejo/forgejo/forgejo/`...

❤️ 4

n0toose commented

2023-07-12 12:56:53 +02:00

Member

Abuse-related vector: If a username (e.g. https://codeberg.org/forgejo) is registered, alert the owners of https://codeberg.org/organization/forgejo) and maybe the admins and make such behavior optionally prohibited?

(or redirect https://codeberg.org/forgejo to https://codeberg.org/organization/forgejo)

Abuse-related vector: If a username (e.g. `https://codeberg.org/forgejo`) is registered, alert the owners of `https://codeberg.org/organization/forgejo`) and maybe the admins and make such behavior optionally prohibited? (or redirect `https://codeberg.org/forgejo` to `https://codeberg.org/organization/forgejo`)

crystal commented

2023-08-17 17:20:14 +02:00

Owner

iirc, GitLab allows you to organize repos inside subprojects, and these can be nested as much or as little as you like. It would be nice if we had an implementation like this. I feel it's pretty important for us to avoid breaking the current URL paradigm, so even if you wouldn't be able to nest these subprojects, I think you should be able to have some repos in the root of your organization.

Example:

https://codeberg.org/forgejo/forgejo
https://codeberg.org/forgejo/website/source
https://codeberg.org/forgejo/website/docs

You should be able to have a setup like this where some repos are organized into subprojects and others are not.

@n0toose I think you misunderstood the request, the org would still own the username @forgejo and the URI /forgejo

iirc, GitLab allows you to organize repos inside subprojects, and these can be nested as much or as little as you like. It would be nice if we had an implementation like this. I feel it's pretty important for us to avoid breaking the current URL paradigm, so even if you wouldn't be able to nest these subprojects, I think you should be able to have some repos in the root of your organization. Example: - `https://codeberg.org/forgejo/forgejo` - `https://codeberg.org/forgejo/website/source` - `https://codeberg.org/forgejo/website/docs` You should be able to have a setup like this where some repos are organized into subprojects and others are not. @n0toose I think you misunderstood the request, the org would still own the username @forgejo and the URI `/forgejo`

👍 19

n0toose commented

2023-08-17 17:24:28 +02:00

Member

@n0toose I think you misunderstood the request, the org would still own the username @forgejo and the URI /forgejo

I did. Here's a small update: I got in touch with the president of an association IRL that actually uses Gitea in the background, and they brought up to me "how the only thing they're missing is this feature". There are also requests under Codeberg/Community which want something like this, as well as organizations that would like to migrate away from GitLab and their user limit while retaining the URL structure they previously had in place.

I was thinking about this as I was grocery shopping 5 days ago: Would it be possible for a subproject to have an organization "parent" that can be changed at a later point in time? I could imagine several benefits for basically everyone.

> @n0toose I think you misunderstood the request, the org would still own the username @forgejo and the URI /forgejo I did. Here's a small update: I got in touch with the president of an association IRL that actually uses Gitea in the background, and they brought up to me "how the only thing they're missing is this feature". There are also requests under `Codeberg/Community` which want something like this, as well as organizations that would like to migrate away from GitLab and their user limit while retaining the URL structure they previously had in place. I was thinking about this as I was grocery shopping 5 days ago: Would it be possible for a subproject to have an organization "parent" that can be changed at a later point in time? I could imagine several benefits for basically everyone.

❤️ 2

caesar commented

2023-08-17 23:23:04 +02:00

Member

Would it be possible for a subproject to have an organization "parent" that can be changed at a later point in time?

That's good point, a subproject should be able to be transferred to another user/org just like a repo can.

> Would it be possible for a subproject to have an organization "parent" that can be changed at a later point in time? That's good point, a subproject should be able to be transferred to another user/org just like a repo can.

👍 6

Beowulf commented

2024-06-15 19:26:14 +02:00

Owner

I think (sub)*-organizations would be a good feature and at least in conversations with other people and also in the Fediverse I often see that it is mentioned that these are missing. — I have to say I miss the function too. On my private instance, I have many repos in an organization that start with the same group name because otherwise there is no good structure for organizing.

In principle, the same is requested in #1710.
Shall we adjust the title here to better reflect what is meant (e.g. in "Support for (nested) sub-organizations")?

I think (sub)*-organizations would be a good feature and at least in conversations with other people and also in the Fediverse I often see that it is mentioned that these are missing. — I have to say I miss the function too. On my private instance, I have many repos in an organization that start with the same group name because otherwise there is no good structure for organizing. In principle, the same is requested in #1710. Shall we adjust the title here to better reflect what is meant (e.g. in "Support for (nested) sub-organizations")?

ltdk commented

2024-07-21 23:36:47 +02:00

I also would like to second this as a form of organisation-- back when I had my own instance, I made a lot of orgs for this purpose. It would be lovely to be able to just nest that categorisation directly under my user.

earl-warren commented

2024-07-22 06:27:48 +02:00

Contributor

First hand experience go a long way to push a feature request forward. Can you explain in more details what you did and why? This is the best kind of use case. 🙏

ltdk commented

2024-07-22 07:25:11 +02:00

I mean, it's nothing groundbreaking; I just like organising things and when you have a flat hierarchy, it becomes a pain to go through everything. Sure, you can add tags, filter by language, and whatever, but it's nice to have separate layers for sorting out configs, CLI utils, and whatever other categories are relevant.

I haven't moved a whole lot of the repos from my old instance to codeberg yet, but for example, I just moved over about 6 different NPM package repos for various configs and wish I could put them in a separate folder, org, whatever instead of just having them on the singular pile that is my user space.

And sure, I could make an org for them at global scope like clarfonthey-jsconfigs but it just feels bad instead of being able to scope them under my user. Since this is a shared space, and not just my personal dumping ground.

I mean, it's nothing groundbreaking; I just like organising things and when you have a flat hierarchy, it becomes a pain to go through everything. Sure, you can add tags, filter by language, and whatever, but it's nice to have separate layers for sorting out configs, CLI utils, and whatever other categories are relevant. I haven't moved a whole lot of the repos from my old instance to codeberg yet, but for example, I just moved over about 6 different NPM package repos for various configs and wish I could put them in a separate folder, org, whatever instead of just having them on the singular pile that is my user space. And sure, I could make an org for them at global scope like clarfonthey-jsconfigs but it just feels bad instead of being able to scope them under my user. Since this is a shared space, and not just my personal dumping ground.

👍 6

Beowulf commented

2024-07-24 00:48:08 +02:00

Owner

For me, it was the following use case where I would have liked a feature like this: I created an organization for my university stuff, in the organization I then have one repo per module.

In most modules, however, I have several (actually separate) projects. I currently have all projects in one repo (folder structure). On the one hand, this makes it difficult to share a single project and reduces clarity.

For me, it was the following use case where I would have liked a feature like this: I created an organization for my university stuff, in the organization I then have one repo per module. In most modules, however, I have several (actually separate) projects. I currently have all projects in one repo (folder structure). On the one hand, this makes it difficult to share a single project and reduces clarity.

mvdkleijn commented

2024-09-14 21:10:42 +02:00

I'd like to add my 2 cents to this.

First of all, I can completely understand the wish for and usefulness of the "projects/subprojects/suborginizations" idea. In certain use cases I can see that such a nesting of repos in projects in orgs would be useful.

However 😄, I'd also like to point out that there are users (like myself) that quite like the "flat" style.

One of the reasons why I myself don't really like, nor use, Gitlab is that I find their UI/UX cluttered and repos hidden in subprojects can be annoyingly difficult to find at times. That's probably just a kink in my wiring but anyway...

I would therefore like to request that any support of "subprojects" or the like:

does not come with URL changes for existing repos;
is made optional if they are ever implemented in some form;
would still allow repos at the root level;

URL changes especially would potentially break a lot of things IMHO. It'd be even more painful if we have potentially unlimited nesting.

I'd like to add my 2 cents to this. First of all, I can completely understand the wish for and usefulness of the "projects/subprojects/suborginizations" idea. In certain use cases I can see that such a nesting of repos in projects in orgs would be useful. However 😄, I'd also like to point out that there are users (like myself) that quite like the "flat" style. One of the reasons why I myself don't really like, nor use, Gitlab is that I find their UI/UX cluttered and repos hidden in subprojects can be annoyingly difficult to find at times. That's probably just a kink in my wiring but anyway... I would therefore like to request that any support of "subprojects" or the like: - does not come with URL changes for existing repos; - is made optional if they are ever implemented in some form; - would still allow repos at the root level; URL changes especially would potentially break a *lot* of things IMHO. It'd be even more painful if we have potentially unlimited nesting.

algernon commented

2024-09-14 21:19:58 +02:00

Contributor

FWIW, I will be working on addressing this, in a way that will require URL changes initially, but it will be behind an instance-wide setting. I also have a few ideas how to remove that limitation, but I want to see the grouping parts working first.

I'll follow up with more once I start embarking on this adventure, sometime next week, if all goes well.

FWIW, I will be working on addressing this, in a way that *will* require URL changes initially, but it will be behind an instance-wide setting. I also have a few ideas how to remove that limitation, but I want to see the grouping parts working first. I'll follow up with more once I start embarking on this adventure, sometime next week, if all goes well.

❤️ 3

mvdkleijn commented

2024-09-14 21:41:48 +02:00

FWIW, I will be working on addressing this, in a way that will require URL changes initially, but it will be behind an instance-wide setting. I also have a few ideas how to remove that limitation, but I want to see the grouping parts working first.

I'll follow up with more once I start embarking on this adventure, sometime next week, if all goes well.

If its behind an instance wide toggle, that's fine by me. :)

> FWIW, I will be working on addressing this, in a way that *will* require URL changes initially, but it will be behind an instance-wide setting. I also have a few ideas how to remove that limitation, but I want to see the grouping parts working first. > > I'll follow up with more once I start embarking on this adventure, sometime next week, if all goes well. If its behind an instance wide toggle, that's fine by me. :)

ltdk commented

2024-09-14 22:23:47 +02:00

One additional thing worth pointing out is that allowing extra levels of nesting in URLs doesn't mean that all forms of browsing have to be nested that way too. For example, you can think of the Explore page as a completely denested list of all the repos on an instance, and perhaps similar things can be done to the user pages even with these changes.

But I agree that having an instance-wide toggle is a good idea.

One additional thing worth pointing out is that allowing extra levels of nesting in URLs doesn't mean that all forms of browsing have to be nested that way too. For example, you can think of the Explore page as a completely denested list of all the repos on an instance, and perhaps similar things can be done to the user pages even with these changes. But I agree that having an instance-wide toggle is a good idea.

algernon commented

2024-11-06 09:41:14 +01:00

Contributor

I wanted to post a progress update much sooner, but unforeseen circumstances delayed me quite a bit. Nevertheless, here's a short summary of what I've been up to! I've spent quite a while looking into implementing repo groups, and I think there are three major areas that need attention when implementing this:

An extensible database & internal design that will allow sub-groups later.
Adjusting all the places within the codebase that currently construct a repo URL by concatenating {user}/{repo} to use repo.FullName() (or .HTMLURL(), or .APIURL(), or another appropriate accessor).
Figuring out how to route things

Let me elaborate on those!

I think the sensible thing to do would be to implement simple grouping first: no subgroups, no org team permissions yet, just the ability to group repos. This requires plenty of work, and a lot of care already, so in my opinion, it makes sense to implement a minimal thing first. But, do so in a way that won't cause havoc if subgroups or finer grained permissions are to be implemented. Thankfully, since this is entirely new code, this can be achieved with a bit of forethought.

A harder step is adjusting all the places that manually construct URLs - but that isn't very hard either! It does require a great deal of attention, but the necessary changes aren't hard to accomplish.

The hard part is the routing itself. We currently do not have an easy way to group routes and extract parts of it on the group level. Why is that a problem? Because without the ability to do so, how can we tell whether an url like /forgejo/website/src means the forgejo/website repo's src directory, or the src repo of the website group of the forgejo organization? We can tell the difference in the handler, sure, but it is too late by that point.

There are a number of ways to address this:

Break the current URL scheme, and forcibly add the group everywhere. This is obviously not a workable solution, and it would require "ungrouped" repos to have an url like /forgejo/-/forgejo, which just looks wrong. Even if this would be an instance-wide setting, the pattern still feels bad. It is, however, a relatively simple change, which has the benefit that it can be used to test the other parts of the implementation.
Introduce an alternate path scheme for grouped repos: something like /~forgejo/website/src or /@forgejo/website/src. Repos that are part of a group would be addressed with the user/org name prefixed with ~ or @ or /u///o/ or something, while ungrouped repos would remain available under the /{username}/{repo} patttern. This is also relatively simple to implement, and allows testing the rest of the feature, but having two url patterns for very similar purposes is confusing.
Decouple the Repository Home view from other parts: If we treat /{username}/{repo} as one route, and /{username}/{repo}/-/ as another group of routes, then the ambiguity is solved. It does break existing URLs that point to /{username}/{repo}/issues/new and the like, though, and would also break some API routes too. Sadly not a workable solution long-term.
Figure out a way to capture parts of the path at the group level. This would be the ultimate solution, because it would allow us to have a /{username}/{group_or_repo} group, which could determine whether {group_or_repo} is a group, or a repo, and dispatch to further routing based on that information. It would not introduce a new prefix of any kind, nor would it force grouping on every single repo (and thus, would remain compatible with existing URLs).

I've been experimenting with implementing this last one, and while I have not succeeded yet, I have a couple of ideas how to proceed with it further. However, that will take a bit of time, and I'd like the rest of the feature to be testable independently.

So my current plan is to implement simple repo grouping: no subgroups, and no fine-grained permissions. That is, within an organization, every member would be able to create new groups, and freely assign any repo they have access to to any of the available groups within the org. To access these, to avoid having to do an instance-wide setting, I'll go with the /~{username}/{group}/{repo} pattern. Any repository that is part of a group is only accessible through this pattern. Repositories that aren't grouped, would be available both under /~{username}/-/{repo} and the current /{username}/{repo} paths too.

This would be an interim implementation, something that can be tested, but not something that I would deem merge worthy yet. While my original thinking was that an instance-wide setting would be enough to make the feature mergeable, I no longer believe so. Not only would that break existing URLs when enabled, but it would also be incompatible with future versions of the feature. I mean, lets imagine this is behind a setting, and someone sets up an instance. They'll now have /{username}/{group}/{repo} URLs, with - substituted for the group if the repo is "ungrouped". That would be incompatible with the current pattern, and would be incompatible with a future revision of the feature where grouping is optional. It would lead to awkward situations. Some of which could be resolved (by accepting that /{username}/{repo} and /{username}/-/{repo} would mean the same exact thing), but doing so would require permanently carrying workarounds. I'm not a fan of that.

Therefore, I will first focus on the core feature, and on making sure that Forgejo internally constructs URLs through accessors, rather than concatenating strings. This would allow us to take the feature to a test drive, and iron out any design or implementation issues while we figure out how to improve Forgejo's routing to be able to extract patterns from the route at the group, rather than at the handler level.

I hope to have something to play with up quite soon, and will post here once there's something to look at. Stay tuned!

I wanted to post a progress update much sooner, but unforeseen circumstances delayed me quite a bit. Nevertheless, here's a short summary of what I've been up to! I've spent quite a while looking into implementing repo groups, and I think there are three major areas that need attention when implementing this: - An extensible database & internal design that will allow sub-groups later. - Adjusting all the places within the codebase that currently construct a repo URL by concatenating `{user}/{repo}` to use `repo.FullName()` (or `.HTMLURL()`, or `.APIURL()`, or another appropriate accessor). - Figuring out how to route things Let me elaborate on those! I think the sensible thing to do would be to implement simple grouping first: no subgroups, no org team permissions yet, just the ability to group repos. This requires plenty of work, and a lot of care already, so in my opinion, it makes sense to implement a minimal thing first. But, do so in a way that won't cause havoc if subgroups or finer grained permissions are to be implemented. Thankfully, since this is entirely new code, this can be achieved with a bit of forethought. A harder step is adjusting all the places that manually construct URLs - but that isn't very hard either! It does require a great deal of attention, but the necessary changes aren't hard to accomplish. The hard part is the routing itself. We currently do not have an easy way to group routes and extract parts of it on the group level. Why is that a problem? Because without the ability to do so, how can we tell whether an url like `/forgejo/website/src` means the `forgejo/website` repo's `src` directory, or the `src` repo of the `website` group of the `forgejo` organization? We can tell the difference in the handler, sure, but it is too late by that point. There are a number of ways to address this: - Break the current URL scheme, and forcibly add the group *everywhere*. This is obviously not a workable solution, and it would require "ungrouped" repos to have an url like `/forgejo/-/forgejo`, which just looks wrong. Even if this would be an instance-wide setting, the pattern still feels bad. It is, however, a relatively simple change, which has the benefit that it can be used to test the *other* parts of the implementation. - Introduce an alternate path scheme for grouped repos: something like `/~forgejo/website/src` or `/@forgejo/website/src`. Repos that are part of a group would be addressed with the user/org name prefixed with `~` or `@` or `/u/`/`/o/` or something, while ungrouped repos would remain available under the `/{username}/{repo}` patttern. This is also relatively simple to implement, and allows testing the rest of the feature, but having two url patterns for very similar purposes is confusing. - Decouple the Repository Home view from other parts: If we treat `/{username}/{repo}` as one route, and `/{username}/{repo}/-/` as another *group* of routes, then the ambiguity is solved. It does break existing URLs that point to `/{username}/{repo}/issues/new` and the like, though, and would also break some API routes too. Sadly not a workable solution long-term. - Figure out a way to capture parts of the path at the group level. This would be the ultimate solution, because it would allow us to have a `/{username}/{group_or_repo}` group, which could determine whether `{group_or_repo}` is a group, or a repo, and dispatch to further routing based on that information. It would not introduce a new prefix of any kind, nor would it force grouping on every single repo (and thus, would remain compatible with existing URLs). I've been experimenting with implementing this last one, and while I have not succeeded yet, I have a couple of ideas how to proceed with it further. However, that will take a bit of time, and I'd like the rest of the feature to be testable independently. So my current plan is to implement simple repo grouping: no subgroups, and no fine-grained permissions. That is, within an organization, every member would be able to create new groups, and freely assign any repo they have access to to any of the available groups within the org. To access these, to avoid having to do an instance-wide setting, I'll go with the `/~{username}/{group}/{repo}` pattern. Any repository that is part of a group is *only* accessible through this pattern. Repositories that aren't grouped, would be available both under `/~{username}/-/{repo}` and the current `/{username}/{repo}` paths too. This would be an interim implementation, something that can be tested, but not something that I would deem merge worthy yet. While my original thinking was that an instance-wide setting would be enough to make the feature mergeable, I no longer believe so. Not only would that break existing URLs when enabled, but it would also be incompatible with future versions of the feature. I mean, lets imagine this is behind a setting, and someone sets up an instance. They'll now have `/{username}/{group}/{repo}` URLs, with `-` substituted for the group if the repo is "ungrouped". That would be incompatible with the current pattern, and would be incompatible with a future revision of the feature where grouping is optional. It would lead to awkward situations. Some of which could be resolved (by accepting that `/{username}/{repo}` and `/{username}/-/{repo}` would mean the same exact thing), but doing so would require permanently carrying workarounds. I'm not a fan of that. Therefore, I will first focus on the core feature, and on making sure that Forgejo internally constructs URLs through accessors, rather than concatenating strings. This would allow us to take the feature to a test drive, and iron out any design or implementation issues while we figure out how to improve Forgejo's routing to be able to extract patterns from the route at the group, rather than at the handler level. I hope to have something to play with up quite soon, and will post here once there's something to look at. Stay tuned!

❤️ 3

julianfoad commented

2024-11-14 16:08:37 +01:00

Something perhaps not fully explored in this conversation is: Who are we building this for? I note that the original request/suggestion was specifically for Codeberg.

Forgejo (.org main page) says it is a "self-hosted lightweight" forge, but also "focuses on ... scaling ..." That means, apparently, Forgejo is both for personal tiny use cases, and for big multi-tenant operations like Codeberg.

Adequately supporting both tiny and huge cases requires flexibility. Flexibility of the structure.

This request, initially framed as extending the namespace to add one new level, and subsequent discussions to perhaps add multiple levels, is great for big, multi-tenancy deployments.

What about the small end of the scale? In a small scale deployment I would like the ability to drop the "organization" level (because it all belongs to just me or my single org), and just have projects directly at the top level.

Or even -- and let's give this thought a chance before immediately rejecting it -- the possibility to run a single-project (repo) instance. (Need more projects? Spin up more lightweight instances.)

I am not raising this to be argumentative. I have given a lot of thought to the issues of self-sovereign identity and federated services, and the context of hosting them. The "instance of one" principle which applies so well to Fediverse and Matrix servers also applies here -- it is the only way for a tenant to own their own identity (as far as "ownership" goes for DNS), when the software platform is constrained to serving only one domain per deployment. Making services support the "instance of one" paradigm, and be light-weight, is a key enabler of self-sovereign identity. (Making bigger deployments support Bring Your Own Domain multi-tenancy is an alternative.)

In my use cases, I run a personal instance and one for my tiny (personal) company. In both cases I don't need to configure "organisations", and I don't want that part of the UI because it is unnecessary clutter and cognitive load. It's not huge but just seeing "organization" in the UI, or seeing the panel for configuring an org's contact details, puts me off.

However I do find nested project name-spaces to be helpful. Currently I use (abuse) the "organization" level for achieving a single level of nesting. I fill in the "org" name and sometimes the description field; and I leave all the contact details blank. This works ok but it does not give the professional look that I would like to give: I would like my work to be presented with the UI indicating name-spaces but NOT pretending they are "organisations" in the sense of company businesses.

TL;DR: If we make any change, let's make sure we make life better for light-weight single-tenant use cases as well as big ones.

Something perhaps not fully explored in this conversation is: **Who are we building this for?** I note that the original request/suggestion was specifically for Codeberg. Forgejo (.org main page) says it is a "**self-hosted lightweight**" forge, but also "focuses on ... **scaling** ..." That means, apparently, Forgejo is both for personal tiny use cases, and for big multi-tenant operations like Codeberg. Adequately supporting both tiny and huge cases requires flexibility. Flexibility of the structure. This request, initially framed as *extending* the namespace to add one new level, and subsequent discussions to perhaps add multiple levels, is great for *big, multi-tenancy* deployments. What about the **small** end of the scale? In a small scale deployment I would like the ability to drop the "organization" level (because it all belongs to just me or my single org), and just have projects directly at the top level. Or even -- and let's give this thought a chance before immediately rejecting it -- the possibility to run a single-project (repo) instance. (Need more projects? Spin up more lightweight instances.) I am not raising this to be argumentative. I have given a lot of thought to the issues of self-sovereign identity and federated services, and the context of hosting them. The "instance of one" principle which applies so well to Fediverse and Matrix servers also applies here -- it is the only way for a tenant to own their own identity (as far as "ownership" goes for DNS), when the software platform is constrained to serving only one domain per deployment. Making services support the "instance of one" paradigm, and be light-weight, is a key enabler of self-sovereign identity. (Making bigger deployments support Bring Your Own Domain multi-tenancy is an alternative.) In my use cases, I run a personal instance and one for my tiny (personal) company. In both cases I don't need to configure "organisations", and I don't want that part of the UI because it is unnecessary clutter and cognitive load. It's not huge but just seeing "organization" in the UI, or seeing the panel for configuring an org's contact details, puts me off. However I do find nested project name-spaces to be helpful. Currently I use (abuse) the "organization" level for achieving a single level of nesting. I fill in the "org" name and sometimes the description field; and I leave all the contact details blank. This works ok but it does not give the professional look that I would like to give: I would like my work to be presented with the UI indicating name-spaces but NOT pretending they are "organisations" in the sense of company businesses. TL;DR: If we make any change, let's make sure we make life better for light-weight single-tenant use cases as well as big ones.

👍 1

mvdkleijn commented

2024-11-15 12:32:12 +01:00

On top of the "who is this being created for" question above, I'd like to add the following:

While for some users being able to organize their repos under projects is very nice, it isn't necessary for large scale platforms. (see Github)
Please, whatever the outcome is here, do not force people to use a new url structure.

The current structure is both implicitly and explicitly used by many people and tools to integrate with Forgejo and a change here would, IMHO, break a lot of stuff completely unnecessarily.

The /{username}/{reponame} pattern is fairly common and one might even consider it a de-facto standard.

Would a project be used to indicate ownership of a repository or would it simply be a convenient organisational tool? (I'd like to challenge the near automatic assumption that appeared to happen here that projects would imply ownership and permission management)
Should putting a repo in a project automatically mean reflecting that in the url structure? If a project is simply an organizational tool and not tied to ownership and or rights, something like a project being a special tag and some UI/UX changes would be enough.

On top of the "who is this being created for" question above, I'd like to add the following: 1. While for some users being able to organize their repos under projects is very nice, it isn't necessary for large scale platforms. (see Github) 2. Please, whatever the outcome is here, do not force people to use a new url structure. The current structure is both implicitly and explicitly used by many people and tools to integrate with Forgejo and a change here would, IMHO, break a lot of stuff completely unnecessarily. The /{username}/{reponame} pattern is fairly common and one might even consider it a de-facto standard. 3. Would a project be used to indicate ownership of a repository or would it simply be a convenient organisational tool? (I'd like to challenge the near automatic assumption that appeared to happen here that projects would imply ownership and permission management) 4. Should putting a repo in a project automatically mean reflecting that in the url structure? If a project is simply an organizational tool and not tied to ownership and or rights, something like a project being a special tag and some UI/UX changes would be enough.

algernon commented

2024-11-24 10:24:01 +01:00

Contributor

What about the small end of the scale? In a small scale deployment I would like the ability to drop the "organization" level (because it all belongs to just me or my single org), and just have projects directly at the top level.

With an instance-wide flag, that would certainly be a possibility. With what I have in mind - and in the works - for this structure extension, optionally dropping the org/user part of the structure (based on an instance-wide flag) would become easier. Do keep in mind that while it is possible to make the extension backwards compatible (ie, existing URLs do not change), removing a part of the structure is not going to be compatible. If you have an instance with {org}/{repo} structure, and switch to {repo}, URLs will break, and the other way around too.

Or even -- and let's give this thought a chance before immediately rejecting it -- the possibility to run a single-project (repo) instance. (Need more projects? Spin up more lightweight instances.)

I think if you're going that light, you're likely better served by something other than Forgejo.

In my use cases, I run a personal instance and one for my tiny (personal) company. In both cases I don't need to configure "organisations", and I don't want that part of the UI because it is unnecessary clutter and cognitive load. It's not huge but just seeing "organization" in the UI, or seeing the panel for configuring an org's contact details, puts me off.

Can you open a separate issue about dropping the org/user part of the structure, please? As mentioned above, while it shares code common with extension, it also requires very different work under the hood.

TL;DR: If we make any change, let's make sure we make life better for light-weight single-tenant use cases as well as big ones.

I think it will make life better as-it is currently planned: you won't need to create fake orgs to organize your repos, you'll be able to use groups for that. I believe that'll be a considerably nicer experience than fiddling with fake orgs.

> What about the **small** end of the scale? In a small scale deployment I would like the ability to drop the "organization" level (because it all belongs to just me or my single org), and just have projects directly at the top level. With an instance-wide flag, that would certainly be a possibility. With what I have in mind - and in the works - for this structure extension, optionally dropping the org/user part of the structure (based on an instance-wide flag) would become easier. Do keep in mind that while it is possible to make the extension backwards compatible (ie, existing URLs do not change), removing a part of the structure is not going to be compatible. If you have an instance with `{org}/{repo}` structure, and switch to `{repo}`, URLs *will* break, and the other way around too. > Or even -- and let's give this thought a chance before immediately rejecting it -- the possibility to run a single-project (repo) instance. (Need more projects? Spin up more lightweight instances.) I think if you're going that light, you're likely better served by something other than Forgejo. > In my use cases, I run a personal instance and one for my tiny (personal) company. In both cases I don't need to configure "organisations", and I don't want that part of the UI because it is unnecessary clutter and cognitive load. It's not huge but just seeing "organization" in the UI, or seeing the panel for configuring an org's contact details, puts me off. Can you open a separate issue about dropping the org/user part of the structure, please? As mentioned above, while it shares code common with extension, it also requires very different work under the hood. > TL;DR: If we make any change, let's make sure we make life better for light-weight single-tenant use cases as well as big ones. I think it will make life better as-it is currently planned: you won't need to create fake orgs to organize your repos, you'll be able to use groups for that. I believe that'll be a considerably nicer experience than fiddling with fake orgs.

👍 1

algernon commented

2024-11-24 10:50:55 +01:00

Contributor

On top of the "who is this being created for" question above, I'd like to add the following:

While for some users being able to organize their repos under projects is very nice, it isn't necessary for large scale platforms. (see Github)

I would argue that GitHub would be a whole lot more useful if it had repo groups. Large orgs wouldn't have a flat list of a thousand repos, but far better organized groups instead.

Please, whatever the outcome is here, do not force people to use a new url structure.

The goal is to keep the existing /{username}/{reponame} structure for any and all repositories that aren't in groups. Any solution that breaks this, is not an acceptable one in my book. I'm willing to break that structure temporarily, while developing and testing out the rest of the feature (because routing is one of the major pain points), but such a breaking change should not be merged.

With that said, /{username}/{group} would be a similar pattern, but would work with groups, rather than projects. There's precedent for that, though: GitLab does it this way, and so does Gitweb.

Would a project be used to indicate ownership of a repository or would it simply be a convenient organisational tool? (I'd like to challenge the near automatic assumption that appeared to happen here that projects would imply ownership and permission management)

In the initial implementation, a convenient organization tool only. Groups would belong to a user/org. Repositories can either be ungrouped (and remain accessible at /{username}/{reponame}), or can be put into any group the user/org created (and then live at /{username}/{groupname}/{reponame}). A user/org would have full reign on all groups that belong to them.

Later on this can be changed so that organizations would be able to limit which teams can create groups, and groups could be bound to teams too. But that's the future, my initial implementation will not do anything like that (but I'll try to structure the database and the code in a way to make it easier to add that, if need be). But! Even if extended this way, it should be done so in a way that does not place additional burden on those who just want to group up their repos. In other words, the default in this case should be free-for-all-members.

Should putting a repo in a project automatically mean reflecting that in the url structure? If a project is simply an organizational tool and not tied to ownership and or rights, something like a project being a special tag and some UI/UX changes would be enough.

I believe the answer is yes, it should be reflected in the URL structure. It's clearer that way at a glance, for one. It also means we don't have to come up with a weird way to list repos belonging to a given group: /{username}/{group}/ is right there.

> On top of the "who is this being created for" question above, I'd like to add the following: > > 1. While for some users being able to organize their repos under projects is very nice, it isn't necessary for large scale platforms. (see Github) I would argue that GitHub would be a whole lot more useful if it had repo groups. Large orgs wouldn't have a flat list of a thousand repos, but far better organized groups instead. > 2. Please, whatever the outcome is here, do not force people to use a new url structure. The goal is to keep the existing `/{username}/{reponame}` structure for any and all repositories that aren't in groups. Any solution that breaks this, is not an acceptable one in my book. I'm willing to break that structure **temporarily**, while developing and testing out the rest of the feature (because routing is one of the major pain points), but such a breaking change should not be merged. With that said, `/{username}/{group}` would be a similar pattern, but would work with groups, rather than projects. There's precedent for that, though: GitLab does it this way, and so does Gitweb. > 3. Would a project be used to indicate ownership of a repository or would it simply be a convenient organisational tool? (I'd like to challenge the near automatic assumption that appeared to happen here that projects would imply ownership and permission management) In the initial implementation, a convenient organization tool only. Groups would belong to a user/org. Repositories can either be ungrouped (and remain accessible at `/{username}/{reponame}`), or can be put into any group the user/org created (and then live at `/{username}/{groupname}/{reponame}`). A user/org would have full reign on all groups that belong to them. Later on this can be changed so that organizations would be able to limit which teams can create groups, and groups could be bound to teams too. But that's the future, my initial implementation will not do anything like that (but I'll try to structure the database and the code in a way to make it easier to add that, if need be). But! Even if extended this way, it should be done so in a way that does not place additional burden on those who just want to group up their repos. In other words, the default in this case should be free-for-all-members. > 4. Should putting a repo in a project automatically mean reflecting that in the url structure? If a project is simply an organizational tool and not tied to ownership and or rights, something like a project being a special tag and some UI/UX changes would be enough. I believe the answer is yes, it should be reflected in the URL structure. It's clearer that way at a glance, for one. It also means we don't have to come up with a weird way to list repos belonging to a given group: `/{username}/{group}/` is right there.

👍 1

algernon commented

2024-11-24 11:19:40 +01:00

Contributor

A short update here, because I have some good news, and some bad news.

I started experimenting with implementation, and ran into another small roadblock: git repositories on disk are currently structured as {username}/{reponame}.git, which would lead to clashes if we have a repo with the same name in multiple groups of a given user. This will need to be addressed, too. The easiest is to move the git repo along with the grouping, and the code for that kinda already exists: renaming a repo involves moving the underlying git repo, too. The other option would be to give a hidden, unique name to each git repo that only Forgejo would see - this would require no movement of directories, neither in the group case, nor when renaming repos. I feel this would not be worth the implementation effort, however, so I'll stick with moving directories around when changing repo groups.

The good news is, that I think I found a way to address the URL ambiguity problem in a way that is:

backwards compatible, so all existing urls will continue working (a hard requirement anyway)
does not require huge, invasive changes in how URLs are routed within Forgejo
presents a clear separation between repos and groups: looking at an URL like /{username}/{foo} would make it clear whether {foo} is a repo, or a group.

How? /{username}/@{groupname}/{reponame}!

Repository names aren't allowed to have a @ in them, so a leading @ can be used to easily distinguish a group from a repo. This removes any ambiguity from the URL, which is great both for people looking at the URL, and for Forgejo's router. If we wanted to have something like /{username}/{groupname}/{reponame} AND /{username}/{reponame} working at the same time, we'd have to use a route like /{username}/{repo-or-group}, figure out whether it is a repo or a group, and then dispatch the routing to the appropriate place - and this is something the status quo can't do. But if we prefix the group names with a @, we don't have to!

There will still be a bit of a headache organizing the routing code to avoid repetition, but should be considerably easier this way than both the /{username}/{group-or-repo}/* or the /~{username}/{group}/{repo} pattern.

Oh, and there would be no need to use sentinel paths (/{username}/{repo}/-/* & /{username}/{group}/{repo}/-/) either!

If and when subgroups are to be implemented, they can also use a @ prefix for the subgroups. But sub-groups would require more routing changes, if we want to go arbitrary deep. But that's for a future discussion!

A short update here, because I have some good news, and some bad news. I started experimenting with implementation, and ran into another small roadblock: git repositories on disk are currently structured as `{username}/{reponame}.git`, which would lead to clashes if we have a repo with the same name in multiple groups of a given user. This will need to be addressed, too. The easiest is to move the git repo along with the grouping, and the code for that kinda already exists: renaming a repo involves moving the underlying git repo, too. The other option would be to give a hidden, unique name to each git repo that only Forgejo would see - this would require no movement of directories, neither in the group case, nor when renaming repos. I feel this would not be worth the implementation effort, however, so I'll stick with moving directories around when changing repo groups. The good news is, that I think I found a way to address the URL ambiguity problem in a way that is: - backwards compatible, so all existing urls will continue working (a hard requirement anyway) - does not require huge, invasive changes in how URLs are routed within Forgejo - presents a clear separation between repos and groups: looking at an URL like `/{username}/{foo}` would make it clear whether `{foo}` is a repo, or a group. How? `/{username}/@{groupname}/{reponame}`! Repository names aren't allowed to have a `@` in them, so a leading `@` can be used to easily distinguish a group from a repo. This removes any ambiguity from the URL, which is great both for people looking at the URL, and for Forgejo's router. If we wanted to have something like `/{username}/{groupname}/{reponame}` AND `/{username}/{reponame}` working at the same time, we'd have to use a route like `/{username}/{repo-or-group}`, figure out whether it is a repo or a group, and then dispatch the routing to the appropriate place - and this is something the status quo can't do. But if we prefix the group names with a `@`, we don't have to! There will still be a bit of a headache organizing the routing code to avoid repetition, but should be considerably easier this way than both the `/{username}/{group-or-repo}/*` or the `/~{username}/{group}/{repo}` pattern. Oh, and there would be no need to use sentinel paths (`/{username}/{repo}/-/*` & `/{username}/{group}/{repo}/-/`) either! If and when subgroups are to be implemented, they can also use a `@` prefix for the subgroups. But sub-groups would require more routing changes, if we want to go arbitrary deep. But that's for a future discussion!

👍 4

mvdkleijn commented

2024-11-24 15:19:47 +01:00

I like it. This (together with your earlier reply) would mean we'd have groups/projects for those that want it whilst remaining compatible with the current "flat" style. It would even allow for both styles in one user/org space.

edit: sorry for the repost, using gitnext mobile client sometimes seems to do that

I like it. This (together with your earlier reply) would mean we'd have groups/projects for those that want it whilst remaining compatible with the current "flat" style. It would even allow for both styles in one user/org space. *edit*: sorry for the repost, using gitnext mobile client sometimes seems to do that

Ghost commented

2024-11-25 13:01:07 +01:00

indeed, /{username}/@{groupname}/{reponame} sounds like a very good idea.

indeed, `/{username}/@{groupname}/{reponame}` sounds like a very good idea.

algernon commented

2024-11-29 21:27:44 +01:00

Contributor

A bit of a sneak peek!

Most of the routing parts are in place, at least on the web side (I didn't touch the API routes yet, but I expect those to be largely the same work as the web routes, except easier). The database parts feel fine, and I'm slowly going through all the places that construct repo URLs, to make sure they're group-aware. There are surprisingly many places that need changing, but progress is being made!

And yes, this will allow mixing /{username}/{reponame} and /{username}/@{groupname}/{reponame} for the same user/org.

A bit of a sneak peek! Most of the routing parts are in place, at least on the web side (I didn't touch the API routes yet, but I expect those to be largely the same work as the web routes, except easier). The database parts feel fine, and I'm slowly going through all the places that construct repo URLs, to make sure they're group-aware. There are surprisingly many places that need changing, but progress is being made! And yes, this will allow mixing `/{username}/{reponame}` and `/{username}/@{groupname}/{reponame}` for the same user/org.

2024-11-29_21-18-23.png

426 KiB

🎉 9

algernon commented

2024-12-01 16:34:39 +01:00

Contributor

FWIW, I started pushing some code to my a-beautiful-constellation branch. Still lots to do, but some things already work: a repository that's in a group is only accessible with a group URL, and one without a group must be accessed through the usual, group-less path. There's no API to fiddle with groups yet, it's all database hackery for now.

The backing git repository is still ungrouped, though, so while I did change the database to allow the same repo name for a given user (as long as they're in separate groups), it is not actually possible to achieve that, due to the backing git repo always being ungrouped.

FWIW, I started pushing some code to my [a-beautiful-constellation](https://codeberg.org/algernon/forgejo/src/branch/a-beautiful-constellation) branch. Still lots to do, but some things already work: a repository that's in a group is *only* accessible with a group URL, and one without a group must be accessed through the usual, group-less path. There's no API to fiddle with groups yet, it's all database hackery for now. The backing git repository is still ungrouped, though, so while I did change the database to allow the same repo name for a given user (as long as they're in separate groups), it is not actually possible to achieve that, due to the backing git repo always being ungrouped.

❤️ 3

mvdkleijn commented

2024-12-04 17:35:20 +01:00

@algernon are adding API endpoints part of your plan? Asking because I'm maintainer or https://codeberg.org/mvdkleijn/forgejo-sdk and would be happy to add support for them

algernon commented

2024-12-04 19:32:25 +01:00

Contributor

@algernon are adding API endpoints part of your plan?

Yes, API routes will be part of the pull request. I just haven't got around to dealing with them yet. I can ping you when there's something to look at, if you want.

> @algernon are adding API endpoints part of your plan? Yes, API routes will be part of the pull request. I just haven't got around to dealing with them yet. I can ping you when there's something to look at, if you want.

mvdkleijn commented

2024-12-04 19:51:25 +01:00

@algernon

@algernon are adding API endpoints part of your plan?

Yes, API routes will be part of the pull request. I just haven't got around to dealing with them yet. I can ping you when there's something to look at, if you want.

Sounds fine, let me know when. No hurry and no worries though. 😀

@algernon >> @algernon are adding API endpoints part of your plan? > >Yes, API routes will be part of the pull request. I just haven't got around to dealing with them yet. I can ping you when there's something to look at, if you want. Sounds fine, let me know when. No hurry and no worries though. 😀

👍 1

scabala commented

2024-12-05 10:08:46 +01:00

Hello,
for the context, I created account on Codeberg just to comment on this issue.

I really admire Forgejo project and would love to use but this very feature (nested subgroups) is blocking me. I started my journey in Git forges with GitLab and it 'spoiled me' :P I really loved the freedom to nest groups of repositories, being able to organize them in anyway ones wishes. In fact, I like them so much that I even consider writing my own Git server that supports it.

I would like to point one small thing that I thing is crucial for me and other people coming from GitLab - clone URLs without special characters. I do understand that current solution is just a start of implementation and many things can change but I wanted to share my concerns early.

GitLab and other self-hosted solutions (well, basically plain SSH/HTTP server with git but still) allows to have nested groups without clone URLs with special characters, just plain some/nested/path/to/repo.git. For me, the UI part is not that important and can have special characters like @ but for clone URLs it is really, really important to not have it. IT would migrating much harder because @ will become custom Forgejo thing which makes it difficult to seamlessly migrate to from other Git hosting.

I do not mean to sound harsh, just wanted to give my thoughts on the subject. I do appreciate all Forgejo project for its gargantuan effort and @algernon's work on the nested groups subject which is incredible!

Hello, for the context, I created account on Codeberg just to comment on this issue. I really admire Forgejo project and would love to use but this very feature (nested subgroups) is blocking me. I started my journey in Git forges with GitLab and it 'spoiled me' :P I really loved the freedom to nest groups of repositories, being able to organize them in anyway ones wishes. In fact, I like them so much that I even consider writing my own Git server that supports it. I would like to point one small thing that I thing is crucial for me and other people coming from GitLab - clone URLs without special characters. I do understand that current solution is just a start of implementation and many things can change but I wanted to share my concerns early. GitLab and other self-hosted solutions (well, basically plain SSH/HTTP server with `git` but still) allows to have nested groups without clone URLs with special characters, just plain `some/nested/path/to/repo.git`. For me, the UI part is not that important and can have special characters like `@` but for clone URLs it is really, really important to not have it. IT would migrating much harder because `@` will become custom Forgejo thing which makes it difficult to seamlessly migrate to from other Git hosting. I do not mean to sound harsh, just wanted to give my thoughts on the subject. I do appreciate all Forgejo project for its gargantuan effort and @algernon's work on the nested groups subject which is incredible!

👍 2

algernon commented

2024-12-05 10:53:13 +01:00

Contributor

I'm sorry, but I don't see the problem with a Forgejo-specific URL structure.

Every single forge has its own structure today. While the clone URL structure is similar between some of the major forges (though sr.ht with its /~username/reponame pattern is different, and so is git.kernel.org and other gitweb & cgit instances), the URL structure after the repo root has many differences: for example, visiting a file on GitHub has a /{username}/{reponame}/blob/{branch}/{file} pattern, while on Forgejo, it is /{username}/{reponame}/src/branch/{branch}/{file}, and on GitLab, it is /{username}/{reponame}/-/blob/{branch}/{file}.

If you migrate forges, URLs will change. Unless you're self hosting, and re-use the hostname, the clone URL will change too. A few clever rewrites at the reverse proxy level might mitigate this somewhat, but I'm quite sure that would lead to more headaches than the tiny benefit it might provide.

As such, I don't see why a Forgejo-specific structure there would make much of a difference.

But even if it would make a difference, the unfortunate situation is that trying to follow a GitLab-style structure would break existing, valid URLs. We don't break existing URLs.

On top of that, a special-char-less structure with the current Forgejo routing would be very painful to implement, if at all possible. Which char we use, I don't care much, as long as it is a character that can't otherwise appear in repo names. @, +, -, =, !, ~ would all work. I can even make it configurable, I suppose (not initially, though, there's enough to change without having to care about that).

With that said, once I'm done with the initial implementation, anyone's welcome to try their hands on improving it, and perhaps removing the special char limitation. I am not going to do that, I spent more than enough time trying to make it happen as it is, and failed.

I'm sorry, but I don't see the problem with a Forgejo-specific URL structure. Every single forge has its own structure *today*. While the clone URL structure is similar between some of the major forges (though sr.ht with its `/~username/reponame` pattern is different, and so is git.kernel.org and other gitweb & cgit instances), the URL structure *after* the repo root has many differences: for example, visiting a file on GitHub has a `/{username}/{reponame}/blob/{branch}/{file}` pattern, while on Forgejo, it is `/{username}/{reponame}/src/branch/{branch}/{file}`, and on GitLab, it is `/{username}/{reponame}/-/blob/{branch}/{file}`. If you migrate forges, URLs **will** change. Unless you're self hosting, and re-use the hostname, the clone URL will change too. A few clever rewrites at the reverse proxy level might mitigate this somewhat, but I'm quite sure that would lead to more headaches than the tiny benefit it might provide. As such, I don't see why a Forgejo-specific structure there would make much of a difference. But even if it *would* make a difference, the unfortunate situation is that trying to follow a GitLab-style structure would break existing, valid URLs. We don't break existing URLs. On top of that, a special-char-less structure with the current Forgejo routing would be very painful to implement, if at all possible. Which char we use, I don't care much, as long as it is a character that can't otherwise appear in repo names. `@`, `+`, `-`, `=`, `!`, `~` would all work. I can even make it configurable, I suppose (not initially, though, there's enough to change without having to care about that). With that said, once I'm done with the initial implementation, anyone's welcome to try their hands on improving it, and perhaps removing the special char limitation. I am not going to do that, I spent more than enough time trying to make it happen as it is, and failed.

👍 1

scabala commented

2024-12-05 21:37:53 +01:00

Thank you for response.

I was only concerned about clone URLs, not URLs that are used by UI. Those are fairly unified. And yes, I was thinking about self-hosting scenario when you have git.company.com accessible internally and hardcoded in million places.

It's a shame that it's not possible to have subgroup clone URLs without special characters, without breaking existing URLs. I've been working in quite complex codebases in the past so I do understand that even though something might be theoretically possible, it is often impossible to implement it technically.

I want to reiterate my appreciation for your work and by no means I want to sound as negative. I just wanted to point important topic - at least for me.

Thank you for response. I was only concerned about clone URLs, not URLs that are used by UI. Those are fairly unified. And yes, I was thinking about self-hosting scenario when you have `git.company.com` accessible internally and hardcoded in million places. It's a shame that it's not possible to have subgroup clone URLs without special characters, without breaking existing URLs. I've been working in quite complex codebases in the past so I do understand that even though something might be theoretically possible, it is often impossible to implement it technically. I want to reiterate my appreciation for your work and by no means I want to sound as negative. I just wanted to point important topic - at least for me.

👍 2

algernon commented

2024-12-05 22:01:31 +01:00

Contributor

I was only concerned about clone URLs, not URLs that are used by UI.

Clone URLs and URLs used by the UI share a common base. If the UI uses /{username}/@{group}/{reponame}, so will the clone URL. Yes, the rest of the UI URL don't matter when cloning, but because the base is shared, the way UI URLs are structured dictate how clone URLs look, too. If a clone URL would conflict with an UI URL, or make it ambiguous, then that's not a clone URL we can have.

Those are fairly unified. And yes, I was thinking about self-hosting scenario when you have git.company.com accessible internally and hardcoded in million places.

Nothing a recursive search and replace can't solve. And in the very specific case of a forge self-hosted by an organization, it is possible to set up rewrites at the reverse proxy level for specific users/orgs, at least for HTTPS clone URLs, thus preserving the existing structure. It is also possible to do the same for SSH clone URLs, but that might be a little bit more involved.

I want to reiterate my appreciation for your work and by no means I want to sound as negative. I just wanted to point important topic - at least for me.

No problem! I understand the desire to have a special-char-less URL structure, one that resembles an existing pattern more. I tried hard to make that happen, because familiar structures are good. But if we can't have that - and I believe we can't, not without investing way more into it than reasonable -, then /@{groupname}/ isn't terrible, either.

> I was only concerned about clone URLs, not URLs that are used by UI. Clone URLs and URLs used by the UI share a common base. If the UI uses `/{username}/@{group}/{reponame}`, so will the clone URL. Yes, the rest of the UI URL don't matter when cloning, but because the base is shared, the way UI URLs are structured dictate how clone URLs look, too. If a clone URL would conflict with an UI URL, or make it ambiguous, then that's not a clone URL we can have. > Those are fairly unified. And yes, I was thinking about self-hosting scenario when you have `git.company.com` accessible internally and hardcoded in million places. Nothing a recursive search and replace can't solve. And in the very specific case of a forge self-hosted by an organization, it is possible to set up rewrites at the reverse proxy level for specific users/orgs, at least for HTTPS clone URLs, thus preserving the existing structure. It is also possible to do the same for SSH clone URLs, but that might be a little bit more involved. > I want to reiterate my appreciation for your work and by no means I want to sound as negative. I just wanted to point important topic - at least for me. No problem! I understand the desire to have a special-char-less URL structure, one that resembles an existing pattern more. I tried hard to make that happen, because familiar structures are good. But if we can't have that - and I believe we can't, not without investing way more into it than reasonable -, then `/@{groupname}/` isn't terrible, either.

scabala commented

2024-12-07 22:23:17 +01:00

I see, thank you for detailed explanation of problem. Despite my preferences I do respect your work and hope that Forgejo will gain nested subgroups, whatever implementation fits best. Thank you!

❤️ 1

Ghost commented

2024-12-12 18:16:19 +01:00

with the introduction of '@' as "separator" to identify the group, will there be several levels possible? e.g. /@group/foo.git, /@group/foo/bar.git and /@group/foo/bar/baz.git?

Gusted referenced this issue

2024-12-16 02:29:35 +01:00

[FEAT] Supporting groups with subgroups #1710

Ghost commented

2024-12-16 02:43:06 +01:00

It seems there is some discussion related going on in gitea land here. They seem to be suggesting something like org/-/group/repo instead of using @ in any separator.

I don't know if this matters, but I happened to still be following this issue, saw it, and immediately thought of this RFE.

It seems there is some discussion related going on in gitea land [here](https://github.com/go-gitea/gitea/issues/1872#issuecomment-2542690539). They seem to be suggesting something like `org/-/group/repo` instead of using `@` in any separator. I don't know if this matters, but I happened to still be following this issue, saw it, and immediately thought of this RFE.

👍 1

algernon commented

2024-12-16 10:52:11 +01:00

Contributor

That structure can work too, yeah. I think /{owner}/@{group}/{repo} is nicer than /{owner}/-/{group}/{repo}, but from an implementation point of view, the difference is negligible. I can even make it support both, and that'd cost about 3 lines of code (one of them would still need to be the default, but I could make the other work as a kind of alias).

I would like to note, though, that /{owner}/-/{group}/{repo} has one disadvantage: it is harder to extend that to support sub-groups with the current routing architecture, because /{owner}/-/{group}/{subgroup} and /{owner}/-/{group}/{repo} make both ambiguous: we can't decide what the last part is just from the URL alone, we'd have check whether the last part there is a sub-group or a repo, before trying to handle the route further, and that is - as far as I could determine - not possible with the current routing architecture.

If that would be possible, we could just do /{owner}/{group}/{subgroup}/{repo}, without any kind of separator. So in the structure proposed in the Gitea issue, for subgroups, we'd need something like /{owner}/-/{group}/-/{subgroup}/{repo}, and that doesn't look all that good, @ is shorter, and - in my opinion - more expressive.

That structure can work too, yeah. I think `/{owner}/@{group}/{repo}` is nicer than `/{owner}/-/{group}/{repo}`, but from an implementation point of view, the difference is negligible. I can even make it support both, and that'd cost about 3 lines of code (one of them would still need to be the default, but I could make the other work as a kind of alias). I would like to note, though, that `/{owner}/-/{group}/{repo}` has one disadvantage: it is harder to extend that to support sub-groups with the current routing architecture, because `/{owner}/-/{group}/{subgroup}` and `/{owner}/-/{group}/{repo}` make both ambiguous: we can't decide what the last part is just from the URL alone, we'd have check whether the last part there is a sub-group or a repo, before trying to handle the route further, and *that* is - as far as I could determine - not possible with the current routing architecture. If that would be possible, we could just do `/{owner}/{group}/{subgroup}/{repo}`, without any kind of separator. So in the structure proposed in the Gitea issue, for subgroups, we'd need something like `/{owner}/-/{group}/-/{subgroup}/{repo}`, and that doesn't look all that good, `@` is shorter, and - in my opinion - more expressive.

algernon commented

2024-12-16 10:57:40 +01:00

Contributor

with the introduction of '@' as "separator" to identify the group, will there be several levels possible? e.g. /@group/foo.git, /@group/foo/bar.git and /@group/foo/bar/baz.git?

In my initial implementation, I'm focusing on just one level. But in the future, sub-groups would be possible, yes. Subgroups would need a separator too, though, so /{owner}/@{group}/@{subgroup1}/@{subgroup2}/repo, and so on. The hard part there is that sub-groups do require changes in how routing is done, to support arbitrary nesting. Without changes to routing, we can only go up to a limited amount of nesting. That might be enough, though? Perhaps if the limit could be set at compile time?

In any case, I'd first get a single group out, before exploring arbitrary nesting further. A single group will be a large, complex pull request as it is.

> with the introduction of '@' as "separator" to identify the group, will there be several levels possible? e.g. /@group/foo.git, /@group/foo/bar.git and /@group/foo/bar/baz.git? In my initial implementation, I'm focusing on just one level. But in the future, sub-groups would be possible, yes. Subgroups would need a separator too, though, so `/{owner}/@{group}/@{subgroup1}/@{subgroup2}/repo`, and so on. The hard part there is that sub-groups *do* require changes in how routing is done, to support arbitrary nesting. Without changes to routing, we can only go up to a limited amount of nesting. That might be enough, though? Perhaps if the limit could be set at compile time? In any case, I'd first get a single group out, before exploring arbitrary nesting further. A single group will be a large, complex pull request as it is.

Ghost commented

2024-12-16 11:12:53 +01:00

In my initial implementation, I'm focusing on just one level. But in the future, sub-groups would be possible, yes.

sounds good, thanks.

Without changes to routing, we can only go up to a limited amount of nesting. That might be enough,
though? Perhaps if the limit could be set at compile time?

indeed, looking at making it generic at a later point sounds reasonable.

> In my initial implementation, I'm focusing on just one level. But in the future, sub-groups would be possible, yes. sounds good, thanks. > Without changes to routing, we can only go up to a limited amount of nesting. That might be enough, > though? Perhaps if the limit could be set at compile time? indeed, looking at making it generic at a later point sounds reasonable.

furkangkhsn commented

2024-12-16 11:22:03 +01:00

If this is implemented, i will migrate all gits that i manage to forgejo. Thank you.

algernon commented

2024-12-16 14:43:23 +01:00

Contributor

It's not a matter of if, but a matter of when. 😉

(And the answer is "soon")

It's not a matter of *if*, but a matter of *when*. 😉 (And the answer is "soon")

❤️ 5 🎉 7

doasu commented

2024-12-17 02:22:35 +01:00

Contributor

It's not a matter of if, but a matter of when. 😉

(And the answer is "soon")

Hey there,
I would like to thank you SO much for this.

I started using Forgejo only recently, and I'm honestly blown away with how polished it is. It's all I could ever wish for.

This here is the only feature I felt was missing compared to GitLab, mostly because it allows each user/org to organise projects under namespaces without cluttering their 'project root'.

I will most definitely pay for this software.

> It's not a matter of *if*, but a matter of *when*. 😉 > > (And the answer is "soon") Hey there, I would like to thank you SO much for this. I started using Forgejo only recently, and I'm honestly blown away with how polished it is. It's all I could ever wish for. This here is the only feature I felt was missing compared to GitLab, mostly because it allows each user/org to organise projects under namespaces without cluttering their 'project root'. I will most definitely pay for this software.

senorsmile commented

2024-12-19 01:28:29 +01:00

@algernon

FWIW, I started pushing some code to my a-beautiful-constellation branch. Still lots to do, but some things already work: a repository that's in a group is only accessible with a group URL, and one without a group must be accessed through the usual, group-less path. There's no API to fiddle with groups yet, it's all database hackery for now.

The backing git repository is still ungrouped, though, so while I did change the database to allow the same repo name for a given user (as long as they're in separate groups), it is not actually possible to achieve that, due to the backing git repo always being ungrouped.

I wanted to try out the current state, so I built your branch (in Docker as I didn't see instructions on how to build and run locally) and tried to run, but I get permissions errors:

forgejo  | Generating /data/ssh/ssh_host_rsa_key...
forgejo  | su-exec: /usr/local/bin/gitea: Permission denied
forgejo exited with code 0

@algernon > FWIW, I started pushing some code to my [a-beautiful-constellation](https://codeberg.org/algernon/forgejo/src/branch/a-beautiful-constellation) branch. Still lots to do, but some things already work: a repository that's in a group is *only* accessible with a group URL, and one without a group must be accessed through the usual, group-less path. There's no API to fiddle with groups yet, it's all database hackery for now. > > The backing git repository is still ungrouped, though, so while I did change the database to allow the same repo name for a given user (as long as they're in separate groups), it is not actually possible to achieve that, due to the backing git repo always being ungrouped. I wanted to try out the current state, so I built your branch (in Docker as I didn't see instructions on how to build and run locally) and tried to run, but I get permissions errors: ``` forgejo | Generating /data/ssh/ssh_host_rsa_key... forgejo | su-exec: /usr/local/bin/gitea: Permission denied forgejo exited with code 0 ```

Beowulf commented

2024-12-19 18:44:18 +01:00

Owner

@senorsmile I wanted to try out the current state, so I built your branch (in Docker as I didn't see instructions on how to build and run locally)

Have you seen the wiki for building from source: https://forgejo.org/docs/latest/contributor/from-source/ ?

> @senorsmile I wanted to try out the current state, so I built your branch (in Docker as I didn't see instructions on how to build and run locally) Have you seen the wiki for building from source: https://forgejo.org/docs/latest/contributor/from-source/ ?

Frankkkkk commented

2024-12-27 18:42:02 +01:00

Contributor

BTW, there is a 80$ bounty on Gitea related to this issue

BTW, there is a [80$ bounty on Gitea](https://github.com/go-gitea/gitea/issues/24635) related to this issue

doasu commented

2024-12-31 16:16:06 +01:00

Contributor

@Frankkkkk

BTW, there is a 80$ bounty on Gitea related to this issue

I believe you meant this bounty :)

@Frankkkkk > BTW, there is a [80$ bounty on Gitea](https://github.com/go-gitea/gitea/issues/24635) related to this issue I believe you meant [this bounty](https://github.com/go-gitea/gitea/issues/1872) :)

👍 1

algernon commented

2024-12-31 17:41:27 +01:00

Contributor

FWIW, I have no intention whatsoever of contributing to Gitea, so whatever bounty there is up there, is of no relevance to me. (I'm being paid to work on the feature, by the way. Funding isn't a blocker, the complexity and amount of work is what makes things slow - and the holidays right now.)

👍 4

Frankkkkk commented

2024-12-31 22:14:48 +01:00

Contributor

Sure, I don't use Gitea myself either, but I figured it would be easy to cherry-pick the feature either way, as the divergence is not that big yet (hopefully). I but the bounty there because it was already set up, but if the service also exists on Forgejo, I may reconsider

vpeltnt commented

2025-01-23 16:37:14 +01:00

I realize I'm a little late to the party, but we've recently setup a Forgejo test instance and the repo hierarchy question became relevant when thinking about migration of existing repos. Hopefully, another user story might be useful when considering related features.

Our current setup is simply repos on a server in a directory tree accessed via SSH. We have around 400 repos, the current maximum hierarchy depth is 4. One of the hierarchy patterns is client/solution/component/repo{1..n}. The particular names of the levels are not important, it could just as well be solution/system/sub-system/repo{1..n} or a multitude of other things. The fact is that the hierarchy emerged naturally trying to logically organize the repos. I'm sure it's subjective but to me it is easy to navigate a hierarchy like that and find a repo I need without any UI or search.

Coming from this context the limit of two hierarchy levels (user/repo or org/repo) feels very arbitrary. If we take file systems as an analogy, I imagine a hypothetical user who has only ever used systems where only one directory level is supported might ponder why would one ever want more. But if you're used to the freedom of organizing your data in a directory tree, the limit would feel strange and artificial.

We can use workarounds like flattening the hierarchy and composing parts of it into the two available levels (solution/system/sub-system/repo1 -> solution-system/sub-system-repo1), but that is just a workaround. Similar how programmers using languages without support for namespaces invent naming conventions with prefixes to avoid name clashes. You can live with that, but workarounds like that are not adequate replacements for namespaces, directory trees, etc.

So I agree that adding an additional hierarchy level is an improvement, but I think the limit should be higher to no longer be a hindrance to be worked around. In my opinion a hierarchy limit of 8 or 10 would feel comfortable - unlikely to be hit even by compulsive organizers of their repos. :)

I realize I'm a little late to the party, but we've recently setup a Forgejo test instance and the repo hierarchy question became relevant when thinking about migration of existing repos. Hopefully, another user story might be useful when considering related features. Our current setup is simply repos on a server in a directory tree accessed via SSH. We have around 400 repos, the current maximum hierarchy depth is 4. One of the hierarchy patterns is client/solution/component/repo{1..n}. The particular names of the levels are not important, it could just as well be solution/system/sub-system/repo{1..n} or a multitude of other things. The fact is that the hierarchy emerged naturally trying to logically organize the repos. I'm sure it's subjective but to me it is easy to navigate a hierarchy like that and find a repo I need without any UI or search. Coming from this context the limit of two hierarchy levels (user/repo or org/repo) feels very arbitrary. If we take file systems as an analogy, I imagine a hypothetical user who has only ever used systems where only one directory level is supported might ponder why would one ever want more. But if you're used to the freedom of organizing your data in a directory tree, the limit would feel strange and artificial. We can use workarounds like flattening the hierarchy and composing parts of it into the two available levels (solution/system/sub-system/repo1 -> solution-system/sub-system-repo1), but that is just a workaround. Similar how programmers using languages without support for namespaces invent naming conventions with prefixes to avoid name clashes. You can live with that, but workarounds like that are not adequate replacements for namespaces, directory trees, etc. So I agree that adding an additional hierarchy level is an improvement, but I think the limit should be higher to no longer be a hindrance to be worked around. In my opinion a hierarchy limit of 8 or 10 would feel comfortable - unlikely to be hit even by compulsive organizers of their repos. :)

👍 7

mlncn commented

2025-01-28 17:17:35 +01:00

@algernon given that i am at-mentioning you with the @ symbol and presumably would never do that for a group— is it possible still to use a different reserved symbol? Also having two @s in the SSH git clone URI would certainly break some custom scripts. Of the ones you mentioned i personally would prefer a -dash or ~tilde as the marker of a group or folder.

EDIT: i almost suggested migrating existing user paths to @ but that would require keeping track of the historic paths ensure never breaking redirects created for that move, which understandably is one of the issues we set out to avoid here. Still, i wonder…

Again: Given the association of @ with users and also being a prominent character in SSH git clone, i think it would be unnecessarily confusing to use it to mean group or folder here, so strongly recommend we start off with another character. Thanks!

@algernon given that i am at-mentioning you with the `@` symbol and presumably would never do that for a group— is it possible still to use a different reserved symbol? Also having two `@`s in the SSH git clone URI would certainly break some custom scripts. Of [the ones you mentioned](https://codeberg.org/forgejo/forgejo/issues/1024#issuecomment-2495736) i personally would prefer a -dash or ~tilde as the marker of a group or folder. EDIT: i almost suggested migrating existing user paths to `@` but that would require keeping track of the historic paths ensure never breaking redirects created for that move, which understandably is one of the issues we set out to avoid here. Still, i wonder… Again: Given the association of `@` with users and also being a prominent character in SSH git clone, i think it would be unnecessarily confusing to use it to mean group or folder here, so strongly recommend we start off with another character. Thanks!

👍 6

Froini referenced this issue

2025-01-29 04:19:30 +01:00

[FEAT] Sort by priority associated to labels #660

Carlos17Kopra commented

2025-02-27 00:18:53 +01:00

Im just here to say, that Im really hyped for this Feature to come into Forgejo so I can migrate my Gitlab structure :D

👍 10 🎉 4

becm referenced this issue

2025-02-27 00:48:04 +01:00

feat: global/org level Git hooks #6984

furkangkhsn commented

2025-03-26 07:50:58 +01:00

Is there any updates on this?

👀 13

Gusted referenced this issue

2025-04-16 11:36:04 +02:00

bug: "user does not exist [uid: 0, name: ]" When trying to migrate from Codeberg to Codeberg Organization #7546

Frankkkkk commented

2025-06-14 18:50:27 +02:00

Contributor

If someone is interested, the bounty for the feature is now 480$ on Gitea. I guess it could then be backported easily on forgejo.

Cheers!

If someone is interested, the bounty for the feature is now [480$ on Gitea](https://github.com/go-gitea/gitea/issues/1872#issuecomment-2972681138). I guess it could then be backported easily on forgejo. Cheers!

javerous commented

2025-06-16 16:04:10 +02:00

@algernon Are you still working on this feature ? I checked your worklog and your queue, I didn't see it 😢

@algernon Are you still working on this feature ? I checked your [worklog](https://codeberg.org/algernon/codeberg-worklog/src/branch/main/worklog.md) and your [queue](https://codeberg.org/algernon/codeberg-worklog/src/branch/main/org/queue), I didn't see it 😢

n0toose commented

2025-06-16 22:44:45 +02:00

Member

@javerous Forgejo is a project run by a mix of volunteers (as well as developers that are willing to prioritize certain features for payment sometimes). It seems like the answer is visible in the resources you linked above, so I'd presume that the answer is that algernon is not working on it. We're always looking for people that help us work on heavily requested features or financing their development for the benefit of everyone.

@javerous Forgejo is a project run by a mix of volunteers (as well as developers that are willing to prioritize certain features for payment sometimes). It seems like the answer is visible in the resources you linked above, so I'd presume that the answer is that algernon is not working on it. We're always looking for people that help us work on heavily requested features or [financing their development for the benefit of everyone](https://codeberg.org/forgejo/professional-services).

javerous commented

2025-06-16 22:51:54 +02:00

Sure, I asked because he said in previous messages that he was paid to work on it and funding isn't an issue.

And this message seemed to say that this feature would be available "soon".

Sure, I asked because he said in [previous messages](https://codeberg.org/forgejo/forgejo/issues/1024#issuecomment-2557698) that he was paid to work on it and funding isn't an issue. And [this message](https://codeberg.org/forgejo/forgejo/issues/1024#issuecomment-2518836) seemed to say that this feature would be available "soon".

rawkode commented

2025-06-19 21:13:52 +02:00

The bounty on Gitea is now $900. I'd prefer to see this feature on Forgejo, and I'm happy to make that bounty available for it's implementation here.

👍 1

Beowulf commented

2025-06-19 22:19:34 +02:00

Owner

I think these kinds of messages aren't helpful. First of all here exist is also the possibility to receive money, additionally if someone is interested in the bounty at Gitea, they can check it there.

👍 2

earl-warren commented

2025-06-19 22:25:41 +02:00

Contributor

At 60$/h this pays for 15h of work. I strongly suspect this feature requires an order of magnitude more time to be implemented properly (from implementor and reviewers alike). It is of course a lot less work for a quick implementation with no tests, but that won't be merged in Forgejo.

IIRC there has been one patch merged in to collect a 5,000€ bounty two three years ago in Gitea, related to refactoring user settings. It has never been used after that. If you take a look at it, that will put things in perspective.

At 60$/h this pays for 15h of work. I strongly suspect this feature requires an order of magnitude more time to be implemented properly (from implementor and reviewers alike). It is of course a lot less work for a quick implementation with no tests, but that won't be merged in Forgejo. IIRC there has been one patch merged in to collect a 5,000€ bounty two three years ago in Gitea, related to refactoring user settings. It has never been used after that. If you take a look at it, that will put things in perspective.

👍 2

ashimokawa commented

2025-06-20 13:10:02 +02:00

Member

FYI, [redacted] has registrered 27 accounts on codeberg.org and just does not stop annoying us, even though he has been banned from here.

forgejo-moderation commented

2025-06-20 14:16:47 +02:00

Owner

A message from an account created to circumvent a ban from Forgejo spaces were deleted, please get in touch with the moderation team for more information or checkout the moderation process.

A message from an account created to circumvent a ban from Forgejo spaces were deleted, please [get in touch with the moderation team](https://codeberg.org/forgejo/governance/src/branch/main/MODERATION-PROCESS.md#moderation-contact) for more information or checkout the [moderation process](https://codeberg.org/forgejo/governance/src/branch/main/MODERATION-PROCESS.md).

ashimokawa commented

2025-06-20 14:16:58 +02:00

Member

And yes, here is your place, you can ban anyone who isn't welcomed

Then please respect it already. Don't come back.

> And yes, here is your place, you can ban anyone who isn't welcomed Then please respect it already. Don't come back.

Frankkkkk commented

2025-06-20 14:45:34 +02:00

Contributor

@ashimokawa wrote in #1024 (comment):

FYI, [redacted] has registrered 27 accounts on codeberg.org and just does not stop annoying us, even though he has been banned from here.

Maybe let he speak? I don't really see what he said wrongly...

I hope forgejo/codeberg doesn't become an echo chamber, it would be a shame for us :(

@ashimokawa wrote in https://codeberg.org/forgejo/forgejo/issues/1024#issuecomment-5497418: > FYI, [redacted] has registrered 27 accounts on codeberg.org and just does not stop annoying us, even though he has been banned from here. Maybe let he speak? I don't really see what he said wrongly... I hope forgejo/codeberg doesn't become an echo chamber, it would be a shame for us :(

ashimokawa commented

2025-06-20 15:36:39 +02:00

Member

@Frankkkkk

I did not remove his comments, that is the decision of forgejo moderation which I do not interfere with.
He harassed members of forgejo in the past, so he was banned from the org, and he does not respect that but created accounts to circumvent that. And that is a no-go on our platform, and therefore I block him from codeberg.org

@Frankkkkk I did not remove his comments, that is the decision of forgejo moderation which I do not interfere with. He harassed members of forgejo in the past, so he was banned from the org, and he does not respect that but created accounts to circumvent that. And that is a no-go on our platform, and therefore I block him from codeberg.org

mwerle commented

2025-10-07 08:44:15 +02:00

Hi, just piping in to say I am also very keen for being able to nest repositories in directories. I can do it on a filesystem, so having the flat organisation in GitHub always felt weird and restrictive to me. In fact, having looked at Gitea (sorry) in the past, the only reason I did not go ahead with deploying it was the lack of nesting. So I stuck with Gitolite and Gitweb, as rudimentary and cumbersome as those are..

Here's to hoping @algernon can finish this feature "soon" :)

Hi, just piping in to say I am also very keen for being able to nest repositories in directories. I can do it on a filesystem, so having the flat organisation in GitHub always felt weird and restrictive to me. In fact, having looked at Gitea (sorry) in the past, the only reason I did not go ahead with deploying it was the lack of nesting. So I stuck with Gitolite and Gitweb, as rudimentary and cumbersome as those are.. Here's to hoping @algernon can finish this feature "soon" :)

👎 2

n0toose commented

2025-10-07 08:54:16 +02:00

Member

Could a mod just lock this thread at this point?

vpeltnt commented

2025-10-07 09:30:51 +02:00

@n0toose wrote in #1024 (comment):

Could a mod just lock this thread at this point?

I understand new iterations of posts "I want this too" may seem unproductive. But maybe the underlying problem is the unclear status of this issue?

It's been almost 10 months since @algernon commented the feature should be implemented "soon", so it would be good to have a status update. If @algernon is no longer working on this, that would also be useful information to possibly encourage someone else to take-over. What might also be useful (especially if someone were to take over) is for some core developer to outline the scope of the task at the technical level, any non-obvious but necessary changes, etc. That would help a potential contributor understand the scope to avoid situations were a task is picked up but not completed because it is more involved than it may have seemed to someone not experienced with the codebase. It would also serve as acceptability criteria to minimise the number of iterations needed to make the feature mergeable.

I realise this requires some time from someone who is experienced with the codebase. But getting annoyed at follow-ups is also not productive until at least the status is clearly communicated.

@n0toose wrote in https://codeberg.org/forgejo/forgejo/issues/1024#issuecomment-7579516: > Could a mod just lock this thread at this point? I understand new iterations of posts "I want this too" may seem unproductive. But maybe the underlying problem is the unclear status of this issue? It's been almost 10 months since @algernon commented the feature should be implemented "soon", so it would be good to have a status update. If @algernon is no longer working on this, that would also be useful information to possibly encourage someone else to take-over. What might also be useful (especially if someone were to take over) is for some core developer to outline the scope of the task at the technical level, any non-obvious but necessary changes, etc. That would help a potential contributor understand the scope to avoid situations were a task is picked up but not completed because it is more involved than it may have seemed to someone not experienced with the codebase. It would also serve as acceptability criteria to minimise the number of iterations needed to make the feature mergeable. I realise this requires some time from someone who is experienced with the codebase. But getting annoyed at follow-ups is also not productive until at least the status is clearly communicated.

👍 6

earl-warren referenced this issue

2025-10-07 11:06:11 +02:00

feat: extend Forgejo URL structure from organisation/repository to organisation/project/repository #9550

earl-warren commented

2025-10-07 11:11:33 +02:00

Contributor

I took the time to read through this very old feature request and find it not only interesting but also with a number of first hand experiences (which are, IMHO, the best way to support a feature request).

It was a very long read and probably discouraging for newcomers so I took the time to summarize it at #9550 so it is easier to digest. I hope it contributes to continue the conversation in a productive way.

On the matter of @algernon work, it is pretty much like with any other Free Software contributors: sometime life gets in the way and it is up to someone else to continue the work that was started. There are a lot of good bits and drafted code to re-use and I hope I referenced the important ones in the summary at #9550

I took the time to read through this very old feature request and find it not only interesting but also with a number of first hand experiences (which are, IMHO, the best way to support a feature request). It was a very long read and probably discouraging for newcomers so I took the time to summarize it at https://codeberg.org/forgejo/forgejo/issues/9550 so it is easier to digest. I hope it contributes to continue the conversation in a productive way. On the matter of @algernon work, it is pretty much like with any other Free Software contributors: sometime life gets in the way and it is up to someone else to continue the work that was started. There are a lot of good bits and drafted code to re-use and I hope I referenced the important ones in the summary at https://codeberg.org/forgejo/forgejo/issues/9550

❤️ 6 🎉 4

bpinsard commented

2025-10-07 15:20:58 +02:00

I have a question because I don't fully understand the details of hard-forking from gitea:
If such a large new feature is implemented in Gitea (https://github.com/go-gitea/gitea/pull/35265 https://github.com/go-gitea/gitea/pull/35295 seems to have made progress... ) could (re:licensing)/would it be ported back to forgejo?
Yes | No | Depends-on-xyz?

Thanks!

I have a question because I don't fully understand the details of hard-forking from gitea: If such a large new feature is implemented in Gitea (https://github.com/go-gitea/gitea/pull/35265 https://github.com/go-gitea/gitea/pull/35295 seems to have made progress... ) could (re:licensing)/would it be ported back to forgejo? Yes | No | Depends-on-xyz? Thanks!

earl-warren commented

2025-10-07 15:41:39 +02:00

Contributor

When hard forking, the internals diverge and such a large feature cannot be cherry-picked to / from Gitea / Forgejo. This matter however is off-topic.

👍 2

earl-warren commented

2025-10-11 11:12:25 +02:00

Contributor

I'll close this as the discussion can now continue at #9550

I'll close this as the discussion can now continue at https://codeberg.org/forgejo/forgejo/issues/9550

👍 1

earl-warren closed this issue

2025-10-11 11:12:28 +02:00

Rows
Columns

[FEAT] Proposal to extend Forgejo URL structure from organisation/repository to organisation/project/repository #1024