On Mon, Jun 25, 2018 at 11:19:51AM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > We seem to match url schemes case-sensitively: > > > > $ git clone SSH://example.com/repo.git > > Cloning into 'repo'... > > fatal: Unable to find remote helper for 'SSH' > > > > whereas rfc3986 is clear that the scheme portion is case-insensitive. > > We probably ought to match at least our internal ones with strcasecmp. > > That may break if somebody at DevToolGroup@$BIGCOMPANY got cute and > named their custom remote helper SSH:// that builds on top of the > normal ssh:// protocol with something extra and gave it to their > developers (and they named the http counterpart that has the same > extra HTTP://, of course). True, though I am on the fence whether that is a property worth maintaining. AFAIK it was not planned and is just a "this is how it happened to work" case that is (IMHO) doing the wrong thing. c.f. https://xkcd.com/1172/ Is this a hypothetical, or do you know of a $BIGCOMPANY that uses this? The only similar case I know of is contrib/persistent-https, where we realized the better way to do it is: [url "my-custom-ssh://"] insteadOf = ssh:// > If we probe for git-remote-SSH first and > then fall back to git-remote-ssh, then we won't break these people, > though. I agree that it may be a good bite-sized #leftoverbit > material. This is probably a little tricky to implement, since there is no git-remote-ssh, and we handle it internally in a totally separate code path. So "probe for git-remote-SSH" is probably not "try to run it", but really "search the PATH for something plausible". That may be good enough. It may also interact in a funny way with our allowed-protocol code, if "SSH" gets a pass as "ssh" under the default config, but actually runs the otherwise-disallowed git-remote-SSH (though one would _hope_ if you have such a git-remote-SSH that it behaves just like an ssh remote). > > We could probably also give an advise() message in the above output, > > suggesting that the problem is likely one of: > > > > 1. They misspelled the scheme. > > > > 2. They need to install the appropriate helper. > > > > This may be a good topic for somebody looking for low-hanging fruit to > > get involved in development (I'd maybe call it a #leftoverbits, but > > since I didn't start on it, I'm not sure if it counts as "left over" ;)). > [..] > It may probably be a good idea to do an advice, but I'd think > "Untable to find remote helper for 'SSH'" may be clear enough. If > anything, perhaps saying "remote helper for 'SSH' protocol" would > make it even clear? I dunno. I think it doesn't help much if the user does not know what a remote helper is, or why Git is looking for one. Though at least it gives a term to start searching for, I guess. The original motivation for my mail was the real-world report at: https://github.com/git/git-scm.com/issues/1219 -Peff
