From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 06 May 2015 17:18:18 GMT
Subject: Re: forcing a user@ into the URL if not present
Message-ID: <xmqqsib9bp5x.fsf@gitster.dls.corp.google.com>
In-Reply-To: <e8793cf6c07dcfcfa835dbc4c438918f@www.dscho.org>

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

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