On 2021-03-16 at 04:38:08, Eli Schwartz wrote: > Why does this even matter? Again, the point here is the assertion by > Drew that, for the purpose of listing a manifest of remotely fetchable > resources, he sees a benefit to having some standard format for the URI > itself, describing how it's intended to be fetched. > > - ftp:// -> use the `ftp` tool > - scp:// -> use the `scp` tool > - http:// -> use the `wget` tool > - git+http:// -> use the `git` tool > > But instead of needing every program with a git integration to > reimplement "recognize git+http and do substring prefix removal before > passing to git", the suggestion is for git to do this. 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'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. Lest you think that only Git has to handle parsing these, the Git LFS project (and every other implementation compatible with Git) has to handle parsing them as well (and related things like url.*.insteadOf), and providing bug-for-bug compatible behavior is generally a hassle. We've run into numerous problems where things aren't exactly the same, and making things more complex by adding an esoteric syntax that few users are likely to use isn't helping. 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. 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. -- brian m. carlson (he/him or they/them) Houston, Texas, US
Attachment:
signature.asc
Description: PGP signature
