Re: [BUG] url schemes should be case-insensitive

Jeff King [off-list ref] 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).  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.

Possibly we should also normalize external helpers (so "FOO://bar" would
always call git-remote-foo, never git-remote-FOO).

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" ;)).

Well, noticing an issue, analysing and discussing potential
improvements and their ramifications is already half the work, so it
does count as left-over, I would say.

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.

On Mon, Jun 25, 2018 at 11:19:51AM -0700, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

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

quoted

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