On Tue, Mar 16, 2021 at 10:21:13AM -0400, Drew DeVault wrote: > > It's difficult enough to handle parsing of SSH specifications and > > distinguish them uniformly from Windows paths (think of an alias named > > "c"), so I'd prefer we didn't add additional complexity to handle this > > case. > > There's no additional complexity here: git remotes are URIs, and any > implementation which parses them as such already deals with this case > correctly. Any implementation which doesn't may face all kinds of > problems as a consequence: SSH without a user specified, HTTPS with > Basic auth in the URI username/password fields (or just the password, > which is also allowed), and so on. Any sane and correct implementation > is pulling in a URI parser here, and if not, I don't think it's fair for > git to constrain itself in order to work around some other project's > bugs. Git remotes are most definitely not just URIs. Some valid remotes are: ".", "foo", "/tmp/foo", "c:\foo", "example.com:foo". The parser inside Git has rules to distinguish these from actual rfc3986-compliant URIs. Now I don't know much about the parsing code in, say, git-lfs, or how much of pain it would be to add a new scheme for something that _does_ conform to rfc3986. But it's not necessarily as easy as "you should be using a compliant URI parser". -Peff
