Simple settings for new mirrors org repos #6719

New Issue

GiteaMirror · 2025-11-02T07:04:39-06:00

GiteaMirror commented

2025-11-02 07:04:39 -06:00

Originally created by @ghost on GitHub (Jan 18, 2021).

Gitea version (or commit ref): HEAD
Git version: 2.28
Operating system: Darwin
Heritage: Helm
K8s distro: K3s
Database:
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
Log gist: n/a

Description

The organization mirrors should be treated specially, as it is probably intended for mirrors. When migrating new repos to the mirrors org the following should be disabled by default: Wiki, Issue Tracker, Projects, Pull Requests.

Otherwise I'm having to go into each mirror I make and uncheck 4-5 checkboxes under repo advanced settings every time I migrate a new repo—an error-prone endeavor.

Originally created by @ghost on GitHub (Jan 18, 2021). - Gitea version (or commit ref): HEAD - Git version: 2.28 - Operating system: Darwin - Heritage: Helm - K8s distro: K3s - Database: - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - Log gist: n/a ## Description The organization `mirrors` should be treated specially, as it is probably intended for mirrors. When migrating new repos to the `mirrors` org the following should be disabled by default: Wiki, Issue Tracker, Projects, Pull Requests. Otherwise I'm having to go into each mirror I make and uncheck 4-5 checkboxes under repo advanced settings every time I migrate a new repo—an error-prone endeavor.

GiteaMirror added the type/enhancement label 2025-11-02 07:04:39 -06:00

GiteaMirror commented

2025-11-02 07:04:39 -06:00

@CirnoT commented on GitHub (Jan 18, 2021):

Default units enabled per-repository and per-user configuration would solve this neatly and be more universal than hardcoding 'mirrors'. We already support this instance-wide, shouldn't be too hard to merge the settings.

@CirnoT commented on GitHub (Jan 18, 2021): Default units enabled per-repository and per-user configuration would solve this neatly and be more universal than hardcoding 'mirrors'. We already support this instance-wide, shouldn't be too hard to merge the settings.

GiteaMirror commented

2025-11-02 07:04:39 -06:00

@lunny commented on GitHub (Jan 23, 2021):

So we could save the per-org units in settings, and when create or migrate repositories to this organization, these units settings could be applied to the repository.

@lunny commented on GitHub (Jan 23, 2021): So we could save the per-org units in settings, and when create or migrate repositories to this organization, these units settings could be applied to the repository.

GiteaMirror commented

2025-11-02 07:04:40 -06:00

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Jan 24, 2021):

as previously voiced, it'd be great if this could be as general (hence non-restricting) as possible.
i.e. a setting could be created for both users and orgs. I, for instance, have a single mirror user (not to take up multiple namespaces), under which I am adding repositories to mirror, as opposed to the OP's use case of setting up mirrors under a mirrors org.
I believe it wouldn't add too much complexity to cover both use cases.

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Jan 24, 2021): as previously voiced, it'd be great if this could be as general (hence non-restricting) as possible. i.e. a setting could be created for *both* users and orgs. I, for instance, have a single `mirror` user (not to take up multiple namespaces), under which I am adding repositories to mirror, as opposed to the OP's use case of setting up mirrors under a `mirrors` org. I believe it wouldn't add too much complexity to cover both use cases.

GiteaMirror commented

2025-11-02 07:04:40 -06:00

@ghost commented on GitHub (Jan 27, 2021):

mirror is probably a better idea as it meets REST conventions in URLs and adds continuity between Gitea sites. I like the idea of consolidation if easter egg type feature. I like @lunny idea it seems simple and complete. The idea of handling repo migrations isn't something I'd considered when opening this.

@ghost commented on GitHub (Jan 27, 2021): `mirror` is probably a better idea as it meets REST conventions in URLs and adds continuity between Gitea sites. I like the idea of consolidation if easter egg type feature. I like @lunny idea it seems simple and complete. The idea of handling repo migrations isn't something I'd considered when opening this.

GiteaMirror commented

2025-11-02 07:04:40 -06:00

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Jan 27, 2021):

I mean, my point kind of was that this is up to the admin, whatever the name of the user/org would be, an instance admin could set that user/org as a "mirror {user,org}" and that would from then on work in a predefined, mirroring way (such as disabled pulls and projects or optionally enabled external issue links) - the exact implementation details are probably up for a debate..
the assumption here being that such mirror {user,org} presumably couldn't post comments etc; a consideration should probably be given to a case when an existing user (who's been active before) is being turned into a mirror user (presumably by error), warning the admin and not allowing such transformation or whatever..
this would need to be thought out properly, should it be a solid feature.

@wULLSnpAXbWZGYDYyhWTKKspEQoaYxXyhoisqHf commented on GitHub (Jan 27, 2021): I mean, my point kind of was that this is up to the admin, whatever the name of the user/org would be, an instance admin could set that user/org as a "mirror {user,org}" and that would from then on work in a predefined, mirroring way (such as disabled pulls and projects or optionally enabled external issue links) - the exact implementation details are probably up for a debate.. the assumption here being that such mirror {user,org} presumably couldn't post comments etc; a consideration should probably be given to a case when an existing user (who's been active before) is being turned into a mirror user (presumably by error), warning the admin and not allowing such transformation or whatever.. this would need to be thought out properly, should it be a solid feature.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#6719