On Tue Mar 16, 2021 at 7:54 AM EDT, brian m. carlson wrote: > I believe this construct is nonstandard. It is better to use standard > URL syntax when possible because it makes it much, much easier for > people to use standard tooling to parse and handle URLs. Such tooling > may have special cases for the HTTP syntax that it doesn't use in MAILTO > syntax, so it's important to pick something that works automatically. It is standard - RFC 3986 section 3.1 permits the + character in URI schemes. The use of protocol "composition", e.g. git+https, is a convention, but not a standard. > > So I'm very much opposed to adding, expanding, or giving any sort of > official blessing to this syntax, especially when there are perfectly > valid and equivalent schemes that are already blessed and registered > with IANA. This convention is blessed by the IANA, given that they have accepted protocol registrations which use this convention: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml > 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. > Lest you think that only Git has to handle parsing these I don't, given that my argument stems from making it easier for third-party applications to deal with git URIs :) > Despite the fact that ssh+git is specified as deprecated, we had > people expect it to magically work and had to support it in Git LFS. Aye, people do expect it to work. The problem is not going to go away.
