Repo names are not case-sensitive (part deux) #2634

New Issue

GiteaMirror · 2025-11-02T04:42:57-06:00

GiteaMirror commented

2025-11-02 04:42:57 -06:00

Originally created by @karlredman on GitHub (Dec 7, 2018).

Hi. Thank you so very much for all of your hard work. I'm not complaining but needing an answer for configuration purposes.

TL;DR: Need a final answer -is it intended/designed that internal representations of repositories are stored in lower case only? No worries either way but I'd like to know if this is a design decision or not.

Thanks.

.... descripton:

relative to #4011

This is still an issue: meaning that repositories via git user are still created in lower case -regardless of mapping. This causes a problem for more complicated setups where repository git mirroring is being used, etc. (i.e. replacing the generated repos with git clone --mirror <repo path> copies. The use case for this is below.

The point is: repositories are being created lower case only.

If I 'create new' repository AppData, selecting to populate files or not, everything is fine. However the repository created is git-repositories/user/appdata.git.

Note that git clone <path>/AppData does work. The issue is that the server-side repo is stored as lowercase only. And this is annoying for scalability and organizational purposes.

The issue is that if I then try to create a repository appdata I get "The repository name is already used."

Am I daft? or are you forcing all repo names to lowercase only on the storage side? If that is the case I will need to make some adjustments.

Use cases for git clone --mirror <repo path> replacement repos:

backups offsite
satellite, decentralized, bare repos (i.e. a laptop that syncs with a desktop where both are running gitea with synchronized repos).
situations where users specify similar names with different case -annoying but it happens)

omg sry multiple edits -more info to make the point...
Scenario (assuming <path>/AppData is an existing repo somewhere):

create repo through interface AppData
review reveals: <path>/gitea-repositories/<user>/appdata.git
test clone Appdata -works ok
git clone --mirror <remote/AppData.git> is broken as a replacement for <path>/gitea-repositories/<user>/appdata.git
mv <path>gitea-repositories/AppData.git <path>gitea-repositories/appdata.git
works!/profit!

Now, there is a discrepancy: users checkout AppData but can't create appdata and previous systems must convert to lower case. Also, for the record, AppData != appdata.

Furthermore, administratively, all scripts that are syncing these repos outside of gitea have to accommodate for the case change in repo names.

It's an integration/migration issue relative to scale.

Thanks for your time. I'll make code suggestions if needed if i can and if wanted. For now I'm just trying to lock down the intended behavior.

[edited to correct clarity]

Originally created by @karlredman on GitHub (Dec 7, 2018). Hi. Thank you so very much for all of your hard work. I'm not complaining but needing an answer for configuration purposes. TL;DR: Need a final answer -is it intended/designed that internal representations of repositories are stored in *lower case only*? No worries either way but I'd like to know if this is a design decision or not. Thanks. .... descripton: relative to #4011 This is still an issue: meaning that repositories via `git` user are still created in lower case -regardless of mapping. This causes a problem for more complicated setups where repository git mirroring is being used, etc. (i.e. replacing the generated repos with `git clone --mirror <repo path>` copies. The use case for this is below. The point is: repositories are being created lower case only. If I 'create new' repository `AppData`, selecting to populate files or not, everything is fine. However the repository created is `git-repositories/user/appdata.git`. Note that `git clone <path>/AppData` **does** work. The issue is that the server-side repo is stored as lowercase only. And this is annoying for scalability and organizational purposes. The issue is that if I then try to create a repository `appdata` I get "The repository name is already used." Am I daft? or are you forcing all repo names to lowercase only on the storage side? If that is the case I will need to make some adjustments. Use cases for `git clone --mirror <repo path>` replacement repos: * backups offsite * satellite, decentralized, bare repos (i.e. a laptop that syncs with a desktop where both are running gitea with synchronized repos). * situations where users specify similar names with different case -annoying but it happens) --- omg sry multiple edits -more info to make the point... Scenario (assuming `<path>/AppData` is an existing repo somewhere): 1. create repo through interface `AppData` 2. review reveals: `<path>/gitea-repositories/<user>/appdata.git` 3. test clone Appdata -works ok 4. `git clone --mirror <remote/AppData.git>` is broken as a replacement for `<path>/gitea-repositories/<user>/appdata.git` 5. `mv <path>gitea-repositories/AppData.git <path>gitea-repositories/appdata.git` 6. works!/profit! Now, there is a discrepancy: users checkout `AppData` but can't create `appdata` and previous systems must convert to lower case. Also, for the record, `AppData` != `appdata`. Furthermore, administratively, all scripts that are syncing these repos outside of `gitea` have to accommodate for the case change in repo names. It's an integration/migration issue relative to scale. Thanks for your time. I'll make code suggestions if needed if i can and if wanted. For now I'm just trying to lock down the intended behavior. [edited to correct clarity]

GiteaMirror closed this issue

2025-11-02 04:42:57 -06:00

GiteaMirror commented

2025-11-02 04:42:58 -06:00

@karlredman commented on GitHub (Dec 7, 2018):

Okay. It appears this is by design. Gogs and GitHub both have the same behavior. However GitLab does not. e.g. Gogs, GitHub, and Gitea considers these to be equal repo names for a specific user: "appdata"/"AppData" while GitLab will allow these to be two different repos.

Closing the ticket. Thanks!

BTW: The motivation for this ticket is that I'm using git clone --mirror to replace some of the gitea managed repos on the back end to sync between repo systems. I agree this is probably and edge case.

@karlredman commented on GitHub (Dec 7, 2018): Okay. It appears this is by design. Gogs and GitHub both have the same behavior. However GitLab does not. e.g. Gogs, GitHub, and Gitea considers these to be equal repo names for a specific user: "appdata"/"AppData" while GitLab will allow these to be two different repos. Closing the ticket. Thanks! BTW: The motivation for this ticket is that I'm using `git clone --mirror` to replace some of the gitea managed repos on the back end to sync between repo systems. I agree this is probably and edge case.

GiteaMirror referenced this issue

2025-11-02 12:12:24 -06:00

[PR #2634] [MERGED] Fix go get response if only app URL is custom in configuration #16514

GiteaMirror referenced this issue

2025-11-02 12:12:29 -06:00

[PR #2640] [MERGED] Fix go get response if only app URL is custom in configuration (#2634) #16518

Sign in to join this conversation.