vscode-gitlens
vscode-gitlens copied to clipboard
github remote not compatible with ssh alias
The Setup
In my ~/.ssh/config I have the following setup:
Host gh
HostName github.com
User git
This gives me a shorthand for github whenever I'm using git, meaning that I can do the following:
git clone gh:gitkraken/vscode-gitlens
# Instead of:
git clone [email protected]:gitkraken/vscode-gitlens
When I do this, however, this becomes the actual remote string for that remote. Meaning, git remote -v returns:
origin gh:gitkraken/vscode-gitlens (push)
origin gh:gitkraken/vscode-gitlens (fetch)
The Issue
When configuring gitlens.remotes, the specification format allows you to recognise your remote by either domain or regex. The domain option, when set to simply gh, does not seem to recognise it, so I assume it's not compatible with ssh remotes. The regex option does seem to work, so I do it like this:
"gitlens.remotes": [{"regex": "gh:.+", "type": "GitHub" }]
When configured using regex and the GitHub remote service, the remote service seems to use regex capture groups to determine the url and the repo, leading it to generate the following URL when using the "open file on remote (web)" option:
https://undefined/undefined/blob/master/src/file.py#L42
In the best case, I can change the regex to (gh):(.+) so that it at least captures the remote path correctly, getting us to:
https://gh/gitkraken/vscode-gitlens/blob/master/src/file.py#L42
...which would almost be correct, with the obvious exception that gh is not an extant domain.
The only way to make it currently work is to use the custom remote service, which is plain silly.
The Solution
This issue comes from assuming that the remote string always contains a domain name, which is not the case when using SSH aliases.
The plugin should default to github.com's URL. A simple way to implement this behaviour is to check if the regex has just one capture group, and in that case, treat it as the remote path, and default the domain to github.com.
GitLens Version
v14.3.0
I agree this is an issue, but thank you for allowing me to realize that using a "type": "Custom" would make this work (good enough for me). For anyone struggling with this issue, you can do (please correct me if I'm wrong, @detuur):
{
"gitlens.integrations.enabled": true,
"gitlens.remotes": [
{
"regex": "(gh):(.+)",
"type": "Custom",
"urls": {
"repository": "https://github.com/${repo}",
"branches": "https://github.com/${repo}/branches",
"branch": "https://github.com/${repo}/commits/${branch}",
"commit": "https://github.com/${repo}/commit/${id}",
"file": "https://github.com/${repo}?path=${file}${line}",
"fileInBranch": "https://github.com/${repo}/blob/${branch}/${file}${line}",
"fileInCommit": "https://github.com/${repo}/blob/${id}/${file}${line}",
"fileLine": "#L${line}",
"fileRange": "#L${start}-L${end}"
}
}
]
}
I use the same ssh alias technique to allow authenticating with Github using different keypairs and have for a long time been confused why none of the advanced features of Gitlens seemed to work.
I noticed when opening the "remotes view", then clicking the little Globe icon showed a dialog that explained that my remote wasn't set up correctly. Then I remembered that I am using an alias. I tried setting up similar to @detuur but didn't work. I found this issue and tried the workaround proposed by @mbaroody This made the remote at least get recognized. But I still don't see any PR links in hovers, which was the main feature I am trying to enable.
I guess after thinking about this some more, it's probably likely that Gitlens will assume that there are no PRs available if the type is custom. So this workaround unfortunately can't help with that.
Ok, came up with a workaround for my specific case. I added another remote using the non-modified ssh URL (containing [email protected]) you get from Github. Then I was able to connect Gitlens to Github and now finally I can at least see the PR links in hovers.