The Name Collision Strategy setting in Configuration → Connections → GitHub Configuration defaults to repo-owner. Changing it to owner-repo does not persist; navigating away and returning shows it reverted to repo-owner. There is no explicit Save button for this setting.
Other settings on the same page auto-save correctly; only this drop-down is affected.
Impact: Repos are being created with the repo-owner naming pattern even after attempting to change the setting — confirming the change is not being persisted at all, not just a UI display issue.
Under the hood
Field appears to map to starredDuplicateStrategy in the configs table (schema: "suffix" | "prefix" | "owner-org", default "suffix"). Guessing that the onChange handler either doesn't fire or the save call silently fails.
Additionally, the docs don't list an environment variable for this field, so I was unable to test or workaround the issue by setting via the compose file.
Change Name Collision Strategy from repo-owner to owner-repo
Navigate to another settings page
Return to GitHub Configuration
Name Collision Strategy is back to repo-owner
Expected
Selection persists after change (auto-save like other dropdowns) or a Save button is present for the setting.
Originally created by @agent00bob on GitHub (Jun 17, 2026).
Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/326
Originally assigned to: @arunavo4 on GitHub.
### Description
The `Name Collision Strategy` setting in Configuration → Connections → GitHub Configuration defaults to `repo-owner`. Changing it to `owner-repo` does not persist; navigating away and returning shows it reverted to `repo-owner`. There is no explicit Save button for this setting.
Other settings on the same page auto-save correctly; only this drop-down is affected.
Impact: Repos are being created with the repo-owner naming pattern even after attempting to change the setting — confirming the change is not being persisted at all, not just a UI display issue.
### Under the hood
Field appears to map to starredDuplicateStrategy in the configs table (schema: "suffix" | "prefix" | "owner-org", default "suffix"). Guessing that the onChange handler either doesn't fire or the save call silently fails.
Additionally, the docs don't list an environment variable for this field, so I was unable to test or workaround the issue by setting via the compose file.
### Environment
- Gitea-Mirror Version: v3.19.1
- Install: Fresh Docker install
- Browser: Firefox
### Steps to Reproduce
1. Configuration → Connections → GitHub Configuration
2. Change `Name Collision Strategy` from `repo-owner` to `owner-repo`
3. Navigate to another settings page
4. Return to GitHub Configuration
5. `Name Collision Strategy` is back to `repo-owner`
### Expected
Selection persists after change (auto-save like other dropdowns) or a Save button is present for the setting.
@agent00bob can you give it a try again with the latest verison. Should be fixed now
<!-- gh-comment-id:4748240879 -->
@arunavo4 commented on GitHub (Jun 19, 2026):
@agent00bob can you give it a try again with the latest verison. Should be fixed now
@agent00bob can you give it a try again with the latest verison. Should be fixed now
@arunavo4 just pulled and tested. Looks to be persisting now. I haven't tried mirroring another repo yet. I renamed the repos manually in Forgejo thinking the sync/mirrors would persist based on the github address, not the repo name. But it looks like it broke them. I'm not sure if that's an issue or just working as designed. So not sure how to test on my sync'd/mirrored repos without removing them and readding.
<!-- gh-comment-id:4754340573 -->
@agent00bob commented on GitHub (Jun 19, 2026):
> [@agent00bob](https://github.com/agent00bob) can you give it a try again with the latest verison. Should be fixed now
@arunavo4 just pulled and tested. Looks to be persisting now. I haven't tried mirroring another repo yet. I renamed the repos manually in Forgejo thinking the sync/mirrors would persist based on the github address, not the repo name. But it looks like it broke them. I'm not sure if that's an issue or just working as designed. So not sure how to test on my sync'd/mirrored repos without removing them and readding.
@arunavo4 okay, looks like it worked. Thanks very much for the quick turn!
<!-- gh-comment-id:4754424159 -->
@agent00bob commented on GitHub (Jun 19, 2026):
@arunavo4 okay, looks like it worked. Thanks very much for the quick turn!
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @agent00bob on GitHub (Jun 17, 2026).
Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/326
Originally assigned to: @arunavo4 on GitHub.
Description
The
Name Collision Strategysetting in Configuration → Connections → GitHub Configuration defaults torepo-owner. Changing it toowner-repodoes not persist; navigating away and returning shows it reverted torepo-owner. There is no explicit Save button for this setting.Other settings on the same page auto-save correctly; only this drop-down is affected.
Impact: Repos are being created with the repo-owner naming pattern even after attempting to change the setting — confirming the change is not being persisted at all, not just a UI display issue.
Under the hood
Field appears to map to starredDuplicateStrategy in the configs table (schema: "suffix" | "prefix" | "owner-org", default "suffix"). Guessing that the onChange handler either doesn't fire or the save call silently fails.
Additionally, the docs don't list an environment variable for this field, so I was unable to test or workaround the issue by setting via the compose file.
Environment
Steps to Reproduce
Name Collision Strategyfromrepo-ownertoowner-repoName Collision Strategyis back torepo-ownerExpected
Selection persists after change (auto-save like other dropdowns) or a Save button is present for the setting.
@arunavo4 commented on GitHub (Jun 19, 2026):
@agent00bob can you give it a try again with the latest verison. Should be fixed now
@agent00bob commented on GitHub (Jun 19, 2026):
@arunavo4 just pulled and tested. Looks to be persisting now. I haven't tried mirroring another repo yet. I renamed the repos manually in Forgejo thinking the sync/mirrors would persist based on the github address, not the repo name. But it looks like it broke them. I'm not sure if that's an issue or just working as designed. So not sure how to test on my sync'd/mirrored repos without removing them and readding.
@arunavo4 commented on GitHub (Jun 19, 2026):
@agent00bob can you maybe give it a try on a fresh sync
@agent00bob commented on GitHub (Jun 19, 2026):
@arunavo4 okay, looks like it worked. Thanks very much for the quick turn!