-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Git SSH submodules that omit "ssh://" no longer work #12295
Comments
Thanks for the report. I believe it was an overlook on my side. |
One thing to add after some additional experimentation, I think the issue may be also because of the fact that this form of URL uses a |
Using
And
The issue here is that the An alternative solution could be to convert a scp-like url to the equivalent starting with Thoughts @weihanglo? |
Thanks for both of your investigations! Oh no, the issue is way thornier than I thought 😞. Using In long-term, we may want to support scp-like URL, but maybe not now given Cargo doesn't support that for direct Adding a test for SSH might be a bit difficult. Thankfully ehuss already setup container tests infra for us. I guess you can take Lines 167 to 168 in b81b251
|
There is also the call to |
Yep, though I expect it's less likely to have a broken relative URL for submodules, since we've checked
Yep it will try fetching it the fail. Not an optimal one though. Do you have any other example of “bad relative URL” that may lead to any confusing error message? Also still open to have an SCP-like URL parser, if it is not too hard to have one. |
Alright, I will try to file a fix tomorrow. @rustbot claim |
@krs98 are you still around having time to work on it? I believe we need to backport to 1.72 beta branch if we manage to have a patch. Feel free to release your assignment if you have no time to file a patch. The command is |
Git only assumes a submodule URL is a relative path if it starts with `./` or `../` [^1]. To fetch the correct repo, we need to construct an aboslute submodule URL. At this moment it comes with some limitations: * GitHub doesn't accept non-normalized URLs wth relative paths. (`ssh://[email protected]/rust-lang/cargo.git/relative/..` is invalid) * `url` crate cannot parse SCP-like URLs. (`[email protected]:rust-lang/cargo.git` is not a valid WHATWG URL) To overcome these, this patch always tries `Url::parse` first to normalize the path. If it couldn't, append the relative path as the last resort and pray the remote git service supports non-normalized URLs. See also rust-lang#12404 and rust-lang#12295. [^1]: <https://git-scm.com/docs/git-submodule>
Git only assumes a submodule URL is a relative path if it starts with `./` or `../` [^1]. To fetch the correct repo, we need to construct an aboslute submodule URL. At this moment it comes with some limitations: * GitHub doesn't accept non-normalized URLs wth relative paths. (`ssh://[email protected]/rust-lang/cargo.git/relative/..` is invalid) * `url` crate cannot parse SCP-like URLs. (`[email protected]:rust-lang/cargo.git` is not a valid WHATWG URL) To overcome these, this patch always tries `Url::parse` first to normalize the path. If it couldn't, append the relative path as the last resort and pray the remote git service supports non-normalized URLs. See also rust-lang#12404 and rust-lang#12295. [^1]: <https://git-scm.com/docs/git-submodule>
Git only assumes a submodule URL is a relative path if it starts with `./` or `../` [^1]. To fetch the correct repo, we need to construct an aboslute submodule URL. At this moment it comes with some limitations: * GitHub doesn't accept non-normalized URLs wth relative paths. (`ssh://[email protected]/rust-lang/cargo.git/relative/..` is invalid) * `url` crate cannot parse SCP-like URLs. (`[email protected]:rust-lang/cargo.git` is not a valid WHATWG URL) To overcome these, this patch always tries `Url::parse` first to normalize the path. If it couldn't, append the relative path as the last resort and pray the remote git service supports non-normalized URLs. See also rust-lang#12404 and rust-lang#12295. [^1]: <https://git-scm.com/docs/git-submodule>
Problem
When using a Git submodule that uses the SSH protocol, Git allows the
ssh://
to be omitted and the URL to be provided in a form such as[email protected]:...
. Previously this worked fine with Cargo, but since some changes a couple of weeks ago related to handling submodules this seems to no longer work. I instead get an error such as the following:As you can see it's failing to parse the
[email protected]:...
URL, it seems to think it's a relative URL, but it is not a relative URL, it is an absolute URL which doesn't specify thessh://
protocol, which is a valid Git submodule URL, so should be supported.I am already using
git-fetch-with-cli = true
in my.cargo/config.toml
file to fix other issues with using SSH authentication to private repositories, but it doesn't seem to fix this issue.Steps
ssh://
prefix.Possible Solution(s)
Any parsing of a Git submodule URL should allow the protocol to be omitted. It may be the call to
Url::parse()
added in the commit 2717a34 which has triggered this, so possibly revert that particular part of the change to use the string verbatim without parsing, as was done before.Notes
No response
Version
Fails using
nightly-2023-06-11
or onwards,nightly-2023-06-10
does not exhibit this issue. The version output on the earliest failing version is:The text was updated successfully, but these errors were encountered: