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

> "Kyle J. McKay" <mackyle@gmail.com> writes:
>
>> 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?