Re: forcing a user@ into the URL if not present

Johannes Schindelin [off-list ref] writes:

quoted

quoted

I haven't seen anybody use such a URL but I would say that is a
natural thing to expect to work, as both username and password are
missing so they should default to some sensible values, in this
case "current user, shouldn't need password", just like
"scheme://site:/" is "port missing so it should default to some
sensible value, appropriate for the scheme".

Yes, that makes total sense to me, too. In fact, I found it rather
clever once I got over the surprise.

Yup, I'd happily call that "clever" ;-)

TBH it does not seem overly urgent to add those tests for the HTTPS
handling. From a cursory look it seems that neither
transport_helper_init()` nor any code in `remote-curl.c` parses the
"<user@password>" part of the URL, or for that matter puts
restrictions on it.

Thanks for checking.