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

From: Jeff King <peff@peff.net>
Date: Mar 16, 2021, 21:28 UTC
Message-ID: <YFEjCU1jgrsPIhvk@coredump.intra.peff.net>
In-Reply-To: <C9YUBUYH7PWU.3PHDZR2YCUEOX@taiga>

On Tue, Mar 16, 2021 at 10:21:13AM -0400, Drew DeVault wrote:

Show 14 quoted lines

> > 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