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

On Jul 22, 2013, at 11:00, Junio C Hamano wrote:

"Kyle J. McKay" [off-list ref] writes:

quoted

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.

Can I send out the change as a 'fixup!' patch?  Or do I need to send a  
new v9 patch series with the documentation update?

OK.

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?

Consider this site:

example.com/
example.com/dir
example.com/dir/sub
example.com/dir/sub/public

Suppose I want to configure a particular key for example.com/dir/sub  
for a particular user, say "contractor".

I can configure:

[http "https://contractor@example.com/dir/sub"]
   sslkey=contractor_key

But then I want to configure a completely different key for the public  
area example.com/dir/sub/public no matter what user.  I just add this:

[http "https://example.com/dir/sub/public"]
   sslkey=public_key

But if entries with usernames take precedence it won't work.  The only  
way to do it is to list every possible user for "example.com/dir1/sub1/ 
public" in its own new section and then continue to add a new config  
section every time a new user name is encountered.

Conversely, if a special key is supposed to be used for the user  
"contractor" everywhere on the site at or below "example.com/dir/sub",  
then the above configuration doesn't work unless user matches take  
precedence.  With the current code, one additional entry would have to  
be added like so:

[http "https://contractor@example.com/dir/sub/public"]
   sslkey=contractor_key

So my thinking was that having user matches take precedence over path  
length matches can result in endless additions to the config file  
(because you have to list all the other users to override a sub area  
and that could be a large list) whereas having path length matches  
take precedence over user matches will only result in a few, finite  
additions to the config file (the number of already-configured items  
with a longer path).