Re: [PATCH v8 4/4] config: allow http.<url>.* any user matching

[Junio C Hamano <gitster@pobox.com>]

"Kyle J. McKay" <mackyle@gmail.com> writes:

> Previously the <url> had to specify an exactly matching user name
> and password if those were present in the url being matched against.
>
> Now the password portion is always ignored and omitting the user
> name from <url> allows it to match against any user name.
>
> Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
> ---
>  Documentation/config.txt |  29 +++--

Thanks.

> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index e461f32..c418adf 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1517,15 +1517,26 @@ http.<url>.*::
>  	Any of the http.* options above can be applied selectively to some urls.
>  	For example "http.https://example.com.useragent" would set the user
>  	agent only for https connections to example.com.  The <url> value
> +	matches a url if it refers to the same scheme, host and port and the
> +	path portion is an exact match or a prefix that matches at a "/"
> +	boundary.  If <url> does not include a user name, it will match a url
> +	with any username otherwise the user name must match as well (the
> +	password part, if present in the url, is always ignored).  Longer <url>
> +	path matches take precedence over shorter matches no matter what order
> +	they occur in.  For example, if both "https://user@example.com/path" and
> +	"https://example.com/path/name" are used as a config <url> value and
> +	then "https://user@example.com/path/name/here" is passed to a git
> +	command, the settings in the "https://example.com/path/name" section
> +	will be preferred because that <url> has a longer path length match than
> +	"https://user@example.com/path" even though the latter did match the
> +	user.  For same length matches, the last one wins except that a same
> +	length <url> match that includes a user name will be preferred over a
> +	same length <url> match that does not.  The urls are normalized before
> +	matching so that equivalent urls that are simply spelled differently
> +	will match properly.  Environment variable settings always override any
> +	matches.  The urls that are matched against are those given directly to
> +	git commands.  This means any urls visited as a result of a redirection
> +	do not participate in matching.

A solid wall of text is somewhat hard to read, so I'd queue the
equivalent of the following "git diff -w" output on top.  I also was
trying to see if we can clarify the "length comparison" only refers
to the length of the path part, excluding the length of "user@"
(i.e. when comparing "https://user@example.com/path" with
"https://example.com/path", they are of the same length), which you
can see in the first three lines below.

diff --git a/Documentation/config.txt b/Documentation/config.txt
index c418adf..635ed5d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1521,9 +1521,11 @@ http.<url>.*::
 	path portion is an exact match or a prefix that matches at a "/"
 	boundary.  If <url> does not include a user name, it will match a url
 	with any username otherwise the user name must match as well (the
-	password part, if present in the url, is always ignored).  Longer <url>
-	path matches take precedence over shorter matches no matter what order
-	they occur in.  For example, if both "https://user@example.com/path" and
+	password part, if present in the url, is always ignored).  A <url>
+	with longer path matches take precedence over shorter matches no matter
+	what order they occur in the configuration file.
++
+For example, if both "https://user@example.com/path" and
 "https://example.com/path/name" are used as a config <url> value and
 then "https://user@example.com/path/name/here" is passed to a git
 command, the settings in the "https://example.com/path/name" section

I am not yet convinced that the precedence rule specified in this
what we want (I do not have an example why it is *not* what we want,
either).  Another definition could be "if user@ is present in the
request, give lower precedence to config entries for the site
without user@ than entries with user@", and I do not have a strong
opinion myself which one between the two is better (and there may be
third and other possible rule).

Comments?