Repository mirroring will not accept git@hostname:path/to/repo.git URL

Must use ssh:// URLs for repository mirroring, the git@hostname kind will not work.

When I was setting up push mirroring on gitlab-ce (currently 16.3.3) I tried to give it the ssh URL that I obtained from the remote server, formatted like git@hostname:path/to/repo.git. It would not accept that URL. I had to change it to ssh://git@hostname/path/to/repo.git before it would work.

Since the former format is what is given by both gitlab and github for SSH access to a repo, I think that mirroring should accept that URL format. I spent about an hour trying to figure out why my URL would not work.

I have not tried pull mirroring as CE does not have it.

Hi,

Yes the documentation here: Push mirroring | GitLab doesn’t explain too much about the formatting. However, when choosing repository mirroring in the project it does have these instructions:

What you have to remember is that whatever is put in that URL field needs to specify for the type of the connection, so it has to being with http://, https://, ssh:// or git:// otherwise how is the Gitlab application going to know it is connecting over SSH?

If you just put git@hostname how is it going to know that is SSH? No protocol is specified. It cannot assume that SSH is default, just like it cannot assume that it is http or https. By providing that info, Gitlab then knows what kind of connection it is making. Gitlab has to differentiate the type of connection based on the info being provided. This is pretty much standard in all applications.

It’s very easy then for parsing the URL field to parse everything to the left of ://, which then means it will see, http, https, ssh, git - and the application can then do if http/https, run this function. If ssh, run this function. If git, run this function. If nothing, then fail because you didn’t tell me what type of connection to make.

Using git clone is no different. If I want to clone over https, I have to write it. Sure, for SSH it’s slightly different, but it cannot be expected to be like that in every case that SSH is being used.

Pull mirroring requires a subscription, so that is only available in paid offerings.

I have two problems with that:

  1. I got the url FROM GITLAB by clicking “Clone” on my second gitlab server and using the “copy url” button for ssh. Is it too much to expect the URL that gitlab provides to work?
  2. You’re right that it says The repository must be accessible over http://, https://, ssh:// or git://. But there was nothing to indicate that the URL actually needs to start with one of those prefixes. When I first encountered it and it didn’t work, I looked over the notes and made sure that the repo was available via ssh, so I was very confused. It took about an hour for me to figure out that I needed to change the URL.

I think it should have done the same thing that eclipse and the commandline git application does – notice the user@hostname format of the URL and deduce that it’s ssh. An alternate solution is to indicate in the notes that the URL must start with one of those four prefixes, that user@hostname format will not work. I like the first option.

Followup: If the format of the URL is not one of the allowed formats, it should indicate that it’s the wrong format. The error message should clearly state what’s wrong with the input.

The only thing it says about a username@hostname format URL is This field is required. Which does not help at all … I had entered a URL, and because that URL was copied straight from the repo page on another gitlab server, I had every reason to think it was valid.

Yes, the documentation as well as the notes in the mirroring section should be a little clearer on what is required. Since Gitlab is a ruby application, it - like most other programming, like python, etc, requires the protocol:// before the connection commands - this is also common in OpenStack with mysql:// or psql:// or rabbitmq:// so it’s not something that is going to change - even in Gitlab. Therefore, whether it is HTTP/HTTPS or SSH, it’s still going to require http:// or https:// or ssh:// for the connection URI.