On Jul 22, 2013, at 11:00, Junio C Hamano wrote:
"Kyle J. McKay" <mackyle@xxxxxxxxx> 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@xxxxxxxxxxx/
path" and
+ "https://example.com/path/name"; are used as a config <url> value
and
+ then "https://user@xxxxxxxxxxx/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@xxxxxxxxxxx/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?
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@xxxxxxxxxxx/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@xxxxxxxxxxx/
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@xxxxxxxxxxx/path"; and
"https://example.com/path/name"; are used as a config <url> value and
then "https://user@xxxxxxxxxxx/path/name/here"; is passed to a git
command, the settings in the "https://example.com/path/name"; section
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@xxxxxxxxxxx/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@xxxxxxxxxxx/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).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html