Cargo does not normalize relative urls for submodules in ssh git dependencies

[liss-h]

Problem

Github does not like relative repository names if you use ssh to download repositories.
I.e. according to github the following is not a valid url to fetch a repo: ssh://git@github.com/owner/repo/../sub
Cargo does not normalize such relative paths for submodules and therefore fails to fetch the submodule if using ssh.

Steps

If you have a crate that depends on a git repo via ssh. E.g.

Cargo.toml

crate = { git = "ssh://git@github.com/owner/repo" }

And that repo has a submodule specified with a relative path. E.g.

.gitmodules

[submodule "sub"]
    path = sub
    url = ../sub

Cargo is not able to fetch the submodule because it doesn't normalize the path; github doesn't like that.
Cargo tries the following:

Updating git repository `ssh://git@github.com/owner/repo`
Updating git submodule `ssh://git@github.com/owner/repo/../sub`

Github then throws an error because owner/repo/../sub is not a valid repository name.

Btw, if you enter this manually in the commandline, i.e. git clone ssh://git@github.com/owner/repo/../sub it doesn't work either, but it does work with http, seems to be a github server-side thing, although I don't know if this is indended or not. Git itself seems to do this normalization so relative submodules using ssh work fine there.

Possible Solution(s)

I guess normalize the repo path if using ssh and hope nothing breaks 😅

Notes

No response

Version

cargo 1.73.0-nightly (7ac9416d8 2023-07-24)
release: 1.73.0-nightly
commit-hash: 7ac9416d82cd4fc5e707c9ec3574d22dff6466e5
commit-date: 2023-07-24
host: x86_64-unknown-linux-musl
libgit2: 1.6.4 (sys:0.17.2 vendored)
libcurl: 8.1.2-DEV (sys:0.4.63+curl-8.1.2 vendored ssl:OpenSSL/1.1.1u)
ssl: OpenSSL 1.1.1u  30 May 2023
os: Alpine Linux 3.17.4 [64-bit]

[weihanglo]

I believe the root cause is #12359. Feel like the possible solution would be:

• Using url when possible (for standard ssh:// protocol).
• Go using strings and non-normalized urls otherwise for scp-like URLs).

Since we never support submodule URL relative to scp-like URL, I think it is fine letting the case fail. Or if there is any scp-like URL parsing we can leverage?