Can't create a necessary group because of "Path is reserved" error

We are currently on a very old version of Gitlab (6.0.1) and I am setting up a newer version (8.2.2) on a whole new machine (so it’s not an in place upgrade, rather a “manual” migration). This machine will eventually be given the same name as the original, so my plan is to set up an identical structure on the new version (i.e. all the groups and repos named the same) so that no one has to change their remotes’ URL.

Most of our current repos are in a Gitlab group called All. In the filesystem this group is stored as all, because that version of Gitlab converted all names to lowercase. This means most remote URLs are of the form git@our-host:all/our_repo.git. I tried creating the same lowercase all group in the new version but I get a “Path is reserved” error.

Is this group name really reserved for internal use or is it just the program just trying to stop me using a generic name? For some reason the name All is allowed, but that would still break all the remote URLs. To change the URLs on everyone’s local clones as well as all the scripts we have that pull and push would be a bit arduous. Is there a way to force Gitlab to create the group anyway, if this doesn’t break any internals?

This is indeed a reserved word that is blacklisted in and was introduced in

i guess there were reasons for this change but you could open an issue and discuss it. Worst case scenario you have to change the code yourself, but that would add extra work on each update.

Update: I got a word from Robert who made that commit:

I think this was added after the @all mentioning was added to GitLab, which conflicts with the group mentioning

So there’s a strong reason this word is blacklisted.

Just a heads up, the list of reserved names is now located in a validator.

Thanks for pointing out the source file, that’s what I needed. I changed it so I could create the group then restored the file. We don’t use any of the “collaboration” functionality of Gitlab, so that shouldn’t be a problem. The ability to preserve the remote URLs is more important for us.