Re: Regarding the depreciation of ssh+git/git+ssh protocols

[Jeff King <peff@peff.net>]

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