When the GitLab instance isn't on the same host as the git remote, the extension can't match git remote with the GitLab instance URL because this matching is based on the host.
For example, if git remote is on git@git.something and the instance on https://gitlab.something, the user has to manually assign each remote to it's GitLab project. The user has to do this for every project on that GitLab instance.
Proposal
If the user manually assigns git@git.something with a project on https://gitlab.something, we could add an extra step that would ask "Would you like to always assign git.something remote URLs with gitlab.something GitLab instance? And if the answer is yes, we could add a setting to the global settings.json. Maybe something like: "gitlab.manuallyMatchedHosts": {"gitlab.something": "git.something"}
I think previously there was a setting "gitlab.instanceUrl": "https://gitlab.instance.de", which worked quite well.
Unfortunately for me it's worse since a few weeks. Our repos have something like:
ssh.git.someurl:group/subgroup/project.git
And with https:
https://git.someurl/group/subgroup/project.git
The lookup always fails and only works if I add a second remote origin_http pointing to that https address. This really sux. I would like to get the option back to just the gitlab.instanceUrl as that worked beautiful and I didn't had to set another remote all the time.
I would like to get the option back to just the gitlab.instanceUrl as that worked beautiful and I didn't had to set another remote all the time.
@steffakasid We had to remove the gitlab.instanceUrl option because it was incompatible with the concept of multiple repositories in one workspace. It worked well in the basic scenario when there was only one repository in the workspace but it got confusing in the edge case when you would use multiple repositories from multiple instances. I'm sorry that the refactoring is a pain for you. You could downgrade the extension version to 3.42.2 to go back to when we used gitlab.instanceUrl.
I think that the proposal suggested in this issue will fix your problem of having to configure every repository.
Also, instead of configuring another remote, you can right-click the failed project in the sidebar and manually assign a GitLab project
Do you mind to explain better what you did? Where did you put this exactly?
Cause settings.json is a Json so it would be nice if you could explain what you did specifically and where you put this.
This effectively causes every git operation that is using git@ssh.git.instance.de: within the remote address to replace the <user>@<dns>: part of the ssh repository url with https://git.instance.de/.
So instead of using ssh in a git clone git@ssh.git.instance.de:foo/bar.git you are effectively using the https url https://git.instance.de/foo/bar.git. The same applies for a git pull when the origin remote in your local repository is git@ssh.git.instance.de:foo/bar.git.
The replacement (when done with git config --global) is applied always and for every git command the user executes.
It's a workaround and works for this problem ... but it's not really nice
Using https and a basic auth challenge instead of ssh when you want to clone/push/pull via ssh url feels kind of weird. Effectively you are always using your API token / GitLab password instead of your local private SSH Key after applying this config.
Personally I'm sticking with manually assigning the project.
For this VSCode extension an ideal solution could exist if the GitLab API would provide an endpoint, where informations about DNS names for https and ssh of the GitLab instance could be retrieved. But as far as I have seen, there is no endpoint that provides this information in the REST API.
Following @viktomas and @steffakasid suggestions above, downgrading to 3.42.2 and setting e.g. "gitlab.instanceUrl": "http://my-instance.gitlab.com" works.
Interestingly, after this i was able to upgrade back to the latest version and assign the project manually (which did not work before). I suppose the extension was still aware of the available repos. Either way, now it works :)