Unable to mirror repository that contains '+' in the name (or create one with such character) #3267

New Issue

GiteaMirror · 2025-11-02T05:06:01-06:00

GiteaMirror commented

2025-11-02 05:06:01 -06:00

Originally created by @arrfab on GitHub (Apr 29, 2019).

Gitea version (or commit ref): 1.8.0
Git version:
Operating system: CentOS 7
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

When trying to create a repository or mirror existing one, Gitea refuses the repository name to contain some characters in the repo string.
Example : try mirroring some repositories from git.centos.org and it will not work :

Repository to mirror : https://git.centos.org/rpms/dvd+rw-tools.git
Repository name (to match with the upstream one) : dvd+rw-tools
Message from Gitea : "Repository name should contain only alphanumeric, dash ('-'), underscore ('_') and dot ('.') characters."

...

Originally created by @arrfab on GitHub (Apr 29, 2019). - Gitea version (or commit ref): 1.8.0 - Git version: - Operating system: CentOS 7 - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x] Yes (provide example URL) - [ ] No - [ ] Not relevant - Log gist: ## Description When trying to create a repository or mirror existing one, Gitea refuses the repository name to contain some characters in the repo string. Example : try mirroring some repositories from git.centos.org and it will not work : Repository to mirror : https://git.centos.org/rpms/dvd+rw-tools.git Repository name (to match with the upstream one) : dvd+rw-tools Message from Gitea : "Repository name should contain only alphanumeric, dash ('-'), underscore ('_') and dot ('.') characters." ...

GiteaMirror added the issue/not-a-bug label 2025-11-02 05:06:01 -06:00

GiteaMirror closed this issue

2025-11-02 05:06:01 -06:00

GiteaMirror commented

2025-11-02 05:06:02 -06:00

@kbsingh commented on GitHub (Apr 29, 2019):

confirming this is a problem with sqlite backend as well

@kbsingh commented on GitHub (Apr 29, 2019): confirming this is a problem with sqlite backend as well

GiteaMirror commented

2025-11-02 05:06:02 -06:00

@techknowlogick commented on GitHub (Apr 29, 2019):

Closing this, as repo names in Gitea should contain only alphanumeric, dash ('-'), underscore ('_') and dot ('.') characters. This is a rule that is enforced by Gitea.

@techknowlogick commented on GitHub (Apr 29, 2019): Closing this, as repo names in Gitea should contain only alphanumeric, dash ('-'), underscore ('_') and dot ('.') characters. This is a rule that is enforced by Gitea.

GiteaMirror commented

2025-11-02 05:06:02 -06:00

@kbsingh commented on GitHub (Jun 26, 2019):

Is there any chance we can get this reconsidered ? not allowing + signs is a problem for anyone working on linux, since + is a valid packagename, filename and widely used in the linux community ( eg. gcc-c++ )

@kbsingh commented on GitHub (Jun 26, 2019): Is there any chance we can get this reconsidered ? not allowing + signs is a problem for anyone working on linux, since + is a valid packagename, filename and widely used in the linux community ( eg. gcc-c++ )

GiteaMirror commented

2025-11-02 05:06:02 -06:00

@lunny commented on GitHub (Jun 26, 2019):

@kbsingh github has the same rule not allowing + in repository name.

@lunny commented on GitHub (Jun 26, 2019): @kbsingh github has the same rule not allowing + in repository name.

GiteaMirror commented

2025-11-02 05:06:03 -06:00

@kbsingh commented on GitHub (Jun 26, 2019):

@lunny thanks, thats an excellent data point!

however, really looking to stick with gitea on self-managed infra. Since we often handle pre-release content etc that could not land in public services etc. Gitblit and a couple of other services seem to handle this without a problem.

What might the major challenges be in adding support for this ?

@kbsingh commented on GitHub (Jun 26, 2019): @lunny thanks, thats an excellent data point! however, really looking to stick with gitea on self-managed infra. Since we often handle pre-release content etc that could not land in public services etc. Gitblit and a couple of other services seem to handle this without a problem. What might the major challenges be in adding support for this ?

GiteaMirror commented

2025-11-02 05:06:03 -06:00

@zeripath commented on GitHub (Jun 26, 2019):

We'd need to ensure that everywhere we use the repository name it's properly escaped - it's currently not escaped anywhere - because it is simply assumed to be safe due to the above constraints - thus enforcing those constraints despite the fact that when not on Windows most of them are irrelevant.

In fact even on Windows they're irrelevant - A repository has an ID number which is unique so why are we storing them as /owner/reponame instead of /repoid? I don't think there's actually a good reason to store them in this way - and if anything it encourages people to think of the gitea repositories as usable from outside of gitea.

Anyway, I've had a look at doing this but it's everywhere - and if we're going to do this we should also ensure that usernames are escaped too for similar reasons.

It is definitely on my list of naughty things that Gogs did that we should not do - but there are more important things that have my focus right now.

You're more than welcome to do the grunt work of doing this kind of PR though - the main issue is making windows compliant directories.

@zeripath commented on GitHub (Jun 26, 2019): We'd need to ensure that everywhere we use the repository name it's properly escaped - it's currently not escaped anywhere - because it is simply assumed to be safe due to the above constraints - thus enforcing those constraints despite the fact that when not on Windows most of them are irrelevant. In fact even on Windows they're irrelevant - A repository has an ID number which is unique so why are we storing them as `/owner/reponame` instead of `/repoid`? I don't think there's actually a good reason to store them in this way - and if anything it encourages people to think of the gitea repositories as usable from outside of gitea. Anyway, I've had a look at doing this but it's everywhere - and if we're going to do this we should also ensure that usernames are escaped too for similar reasons. It is definitely on my list of naughty things that Gogs did that we should not do - but there are more important things that have my focus right now. You're more than welcome to do the grunt work of doing this kind of PR though - the main issue is making windows compliant directories.

GiteaMirror commented

2025-11-02 05:06:03 -06:00

@mrsdizzie commented on GitHub (Jun 26, 2019):

Both Github and Gitlab don't allow + in repo name and many large Linux projects use one of those (Debian, Gnome). This doesn't prevent them from having package names with + in them, they just don't use it in the repo name. For matching example:

https://salsa.debian.org/optical-media-team/dvd-rw-tools

And I agree with @zeripath that it would likely be a lot of work to change properly without introducing bugs, given all of the past bugs related to escaping for things that did allow special characters (branch names for example).

One small and easier to fix bug here is that when you put in a repo with a + in it for migration it shouldn't auto fill the local repo name with the same name that Gitea won't accept though.

@mrsdizzie commented on GitHub (Jun 26, 2019): Both Github and Gitlab don't allow + in repo name and many large Linux projects use one of those (Debian, Gnome). This doesn't prevent them from having package names with + in them, they just don't use it in the repo name. For matching example: https://salsa.debian.org/optical-media-team/dvd-rw-tools And I agree with @zeripath that it would likely be a lot of work to change properly without introducing bugs, given all of the past bugs related to escaping for things that did allow special characters (branch names for example). One small and easier to fix bug here is that when you put in a repo with a + in it for migration it shouldn't auto fill the local repo name with the same name that Gitea won't accept though.

GiteaMirror commented

2025-11-02 05:06:03 -06:00

@kbsingh commented on GitHub (Jun 26, 2019):

@zeripath and @mrsdizzie : appreciate the context and feedback here. Having not touched a windows machine for best part of 2 decades, I'd struggle to do anything meaningful here.

Down the legacy and spread of the instrumentation / tooling around the scm and consumption, we cant rewrite the reponame, but there maybe some option to wrap gitea behind a proxy that does the url mangling. will investigate and scope things out.

thanks and regards,

@kbsingh commented on GitHub (Jun 26, 2019): @zeripath and @mrsdizzie : appreciate the context and feedback here. Having not touched a windows machine for best part of 2 decades, I'd struggle to do anything meaningful here. Down the legacy and spread of the instrumentation / tooling around the scm and consumption, we cant rewrite the reponame, but there maybe some option to wrap gitea behind a proxy that does the url mangling. will investigate and scope things out. thanks and regards,

GiteaMirror commented

2025-11-02 05:06:04 -06:00

@lunny commented on GitHub (Jun 29, 2019):

@zeripath Storing the repository name in server with repository id will make it difficult to migrate or backup I think.

@lunny commented on GitHub (Jun 29, 2019): @zeripath Storing the repository name in server with repository id will make it difficult to migrate or backup I think.

GiteaMirror commented

2025-11-02 05:06:04 -06:00

@zeripath commented on GitHub (Jun 29, 2019):

We can always set the .git/config name. I'm not certain why backup/migrate should be particularly affected - it's only if you selectively backup certain organization's repositories - but that could be done by fixing Gitea dump to work properly.

@zeripath commented on GitHub (Jun 29, 2019): We can always set the .git/config name. I'm not certain why backup/migrate should be particularly affected - it's only if you selectively backup certain organization's repositories - but that could be done by fixing Gitea dump to work properly.

GiteaMirror referenced this issue

2025-11-02 12:20:32 -06:00

[PR #3267] [MERGED] Fixed link to Issue 165 in comment. #16849

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#3267