{"thread":{"id":"34536","subject":"[REQUEST 0/1] Requesting your signed-off-by","startedAt":"2013-07-25T22:39:12Z","lastAt":"2013-07-27T03:04:53Z","messageCount":11,"participants":["Kyle J. McKay","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"224095","messageId":"4b44f95a1b574b5d92a15254e4e8523@f74d39fa044aa309eaea14b9f57fe79","threadId":"34536","inReplyTo":null,"subject":"[REQUEST 0/1] Requesting your signed-off-by","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2013-07-25T22:39:12Z","receivedAt":"2013-07-25T22:39:12Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"Peff,\n\nThe tentative patch included in the following [REQUEST 1/1] message includes\nso much of your suggested text from:\n\n> From: Jeff King \n> Date: July 23, 2013 23:42:59 PDT\n> Subject: Re: [PATCH v8 4/4] config: allow http..* any user matching\n> \n[...]\n> For (1), I wonder if the explanation would be simpler if the precedences\n> of each sub-part were simply laid out. That is, would it be correct to\n> say something like:\n> \n> For a config key to match a URL, each element of the config key (if\n> present) is compared to that of the URL, in the following order:\n> \n> 1. Protocol (e.g., `https` in `https://example.com/`). This field\n> must match exactly between the config key and the URL.\n> \n> 2. Host/domain name (e.g., `example.com` in `https://example.com/`).\n> This field must match exactly between the config key and the URL.\n> \n> 3. Path (e.g., `repo.git` in `https://example.com/repo.git`). This\n> field is prefix-matched by slash-delimited path elements, so that\n> config key `foo/` matches URL `foo/bar`. Longer matches take\n> precedence (so `foo/bar`, if it exists, is a better match than\n> just `foo/`).\n> \n> 4. Username (e.g., `user` in `https://user@example.com/repo.git`).\n> \n> The list above is ordered by decreasing precedence; a URL that matches\n> a config key's path is preferred to one that matches its username.\n\nthat I do not feel comfortable submitting a patch containing it under my name\nwithout your 'Signed-off-by:' as I feel it would be a copyright violation to\ndo otherwise. Since the 'Signed-off-by' mechanism is how the Git project\nhandles this, I'm asking for a reply to the following [REQUEST 1/1] message\nthat includes the full patch text with a 'Signed-off-by' line added from you\nbefore I include it in any patch series (after which I will add my own\n'Signed-off-by' for the other changes I made).\n\nIf you would prefer to simply submit your own patch with the changes,\nI have no objection and will simply refer to that as a required patch instead.\n\nThanks,\n\nKyle\n\n\nKyle J. McKay (1):\n docs: update http..* options documentation\n\n Documentation/config.txt | 60 +++++++++++++++++++++++++++++-------------------\n 1 file changed, 37 insertions(+), 23 deletions(-)\n\n-- \n1.8.3\n"},{"id":"224096","messageId":"ec5ecd4fe44af87e83778ce8e297afe@f74d39fa044aa309eaea14b9f57fe79","threadId":"34536","inReplyTo":"4b44f95a1b574b5d92a15254e4e8523@f74d39fa044aa309eaea14b9f57fe79","subject":"[REQUEST 1/1] docs: update http..* options documentation","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2013-07-25T22:39:13Z","receivedAt":"2013-07-25T22:39:13Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"Overhaul the text of the http..* options documentation\nproviding a hopefully easier to understand itemized list of\nmatching behavior as suggested by and including text from\nJeff King.\n---\n Documentation/config.txt | 60 +++++++++++++++++++++++++++++-------------------\n 1 file changed, 37 insertions(+), 23 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 6b135be..8ff966d 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1515,30 +1515,44 @@ http.useragent::\n \n http..*::\n \tAny of the http.* options above can be applied selectively to some urls.\n-\tFor example \"http.https://example.com.useragent\" would set the user\n-\tagent only for https connections to example.com. The value\n-\tmatches a url if it refers to the same scheme, host and port and the\n-\tpath portion is an exact match or a prefix that matches at a \"/\"\n-\tboundary. If does not include a user name, it will match a url\n-\twith any username otherwise the user name must match as well (the\n-\tpassword part, if present in the url, is always ignored). A \n-\twith longer path matches takes precedence over shorter matches no matter\n-\twhat order they occur in the configuration file.\n+\tFor a config key to match a URL, each element of the config key is\n+\tcompared to that of the URL, in the following order:\n +\n-For example, if both \"https://user@example.com/path\" and\n-\"https://example.com/path/name\" are used as a config value and\n-then \"https://user@example.com/path/name/here\" is passed to a git\n-command, the settings in the \"https://example.com/path/name\" section\n-will be preferred because that has a longer path length match than\n-\"https://user@example.com/path\" even though the latter did match the\n-user. For same length matches, the last one wins except that a same\n-length match that includes a user name will be preferred over a\n-same length match that does not. The urls are normalized before\n-matching so that equivalent urls that are simply spelled differently\n-will match properly. Environment variable settings always override any\n-matches. The urls that are matched against are those given directly to\n-git commands. This means any urls visited as a result of a redirection\n-do not participate in matching.\n+--\n+. Scheme (e.g., `https` in `https://example.com/`). This field\n+ must match exactly between the config key and the URL.\n+. Host/domain name (e.g., `example.com` in `https://example.com/`).\n+ This field must match exactly between the config key and the URL.\n+. Port number (e.g., `8080` in `http://example.com:8080/`).\n+ This field must match exactly between the config key and the URL.\n+ Omitted port numbers are automatically converted to the correct\n+ default for the scheme before matching.\n+. Path (e.g., `repo.git` in `https://example.com/repo.git`). The\n+ path field of the config key must match the path field of the URL\n+ either exactly or as a prefix of slash-delimited path elements. This means\n+ a config key with path `foo/` matches URL path `foo/bar`. A prefix can only\n+ match on a slash (`/`) boundary. Longer matches take precedence (so a config\n+ key with path `foo/bar` is a better match to URL path `foo/bar` than a config\n+ key with just path `foo/`).\n+. Exact user name match (e.g., `user` in `https://user@example.com/repo.git`).\n+ If the config key has a user name it must match the user name in the URL\n+ exactly.\n+. Any user name match. If a config key does not have a user name, that config\n+ key will match a URL with any user name (including none).\n+--\n++\n+The list above is ordered by decreasing precedence; a URL that matches\n+a config key's path is preferred to one that matches its user name. For example,\n+if the URL is `https://user@example.com/foo/bar` a config key match of\n+`https://example.com/foo` will be preferred over a config key match of\n+`https://user@example.com`.\n++\n+All URLs are normalized before attempting any matching (the password part,\n+if embedded in the URL, is always ignored for matching purposes) so that\n+equivalent urls that are simply spelled differently will match properly.\n+Environment variable settings always override any matches. The urls that are\n+matched against are those given directly to Git commands. This means any URLs\n+visited as a result of a redirection do not participate in matching.\n \n i18n.commitEncoding::\n \tCharacter encoding the commit messages are stored in; Git itself\n-- \n1.8.3\n"},{"id":"224104","messageId":"20130726043748.GA20286@sigill.intra.peff.net","threadId":"34536","inReplyTo":"ec5ecd4fe44af87e83778ce8e297afe@f74d39fa044aa309eaea14b9f57fe79","subject":"Re: [REQUEST 1/1] docs: update http..* options documentation","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-07-26T04:37:48Z","receivedAt":"2013-07-26T04:37:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jul 25, 2013 at 03:39:13PM -0700, Kyle J. McKay wrote:\n\n> Overhaul the text of the http..* options documentation\n> providing a hopefully easier to understand itemized list of\n> matching behavior as suggested by and including text from\n> Jeff King.\n> ---\n\nSigned-off-by: Jeff King \n\nYou should add your S-O-B, too, for your bits.\n\n> +--\n> +. Scheme (e.g., `https` in `https://example.com/`). This field\n> + must match exactly between the config key and the URL.\n> +. Host/domain name (e.g., `example.com` in `https://example.com/`).\n> + This field must match exactly between the config key and the URL.\n\nThese look fine in the rendered manpage, but I think the source might be\na little easier to read with a blank line between items.\n\n> +. Port number (e.g., `8080` in `http://example.com:8080/`).\n> + This field must match exactly between the config key and the URL.\n> + Omitted port numbers are automatically converted to the correct\n> + default for the scheme before matching.\n\nThanks, I forgot to include port number in my original suggested text.\n\n> +. Exact user name match (e.g., `user` in `https://user@example.com/repo.git`).\n> + If the config key has a user name it must match the user name in the URL\n> + exactly.\n> +. Any user name match. If a config key does not have a user name, that config\n> + key will match a URL with any user name (including none).\n\nIMHO, this would be more clear as a single item, like:\n\n . User name (e.g., `user` in `https://user@example.com/repo.git`). If\n the config key has a user name it must match the user name in the\n URL exactly. If the config key does not have a user name, that\n config key will match a URL with any user name (including none).\n\n> +All URLs are normalized before attempting any matching (the password part,\n> +if embedded in the URL, is always ignored for matching purposes) so that\n> +equivalent urls that are simply spelled differently will match properly.\n\nAnd this nicely ties up the open questions I had after re-reading the\nlist. Good.\n\nWe could define \"equivalent\" here (the %-encoding thing is obvious, I\nthink, but which components are case-sensitive and which are not is\nperhaps a bit subtle). I do not necessarily know that it is useful to\nthe user, though, and is one more thing to confuse them. And somebody\nwho really cares can look at the appropriate RFCs.\n\nSo this patch looks pretty good to me; the two points I raised above are\nhow I would have done it, but they are relatively minor if you do not\nagree.\n\n-Peff\n"},{"id":"224106","messageId":"7v8v0t50kq.fsf@alter.siamese.dyndns.org","threadId":"34536","inReplyTo":"20130726043748.GA20286@sigill.intra.peff.net","subject":"Re: [REQUEST 1/1] docs: update http..* options documentation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-26T05:53:25Z","receivedAt":"2013-07-26T05:53:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Signed-off-by: Jeff King \n>\n> You should add your S-O-B, too, for your bits.\n> ...\n> So this patch looks pretty good to me; the two points I raised above are\n> how I would have done it, but they are relatively minor if you do not\n> agree.\n\nWill queue the attached, unless you spot glaring errors made by me,\ncoding while drunk ;-)\n\n-- >8 --\nFrom: \"Kyle J. McKay\" \nDate: Thu, 25 Jul 2013 15:39:13 -0700\nSubject: [PATCH] docs: update http..* options documentation\n\nOverhaul the text of the http..* options documentation\nproviding a hopefully easier to understand itemized list of matching\nbehavior as suggested by and including text from Jeff King.\n\nSigned-off-by: Jeff King \nSigned-off-by: Kyle J. McKay \nSigned-off-by: Junio C Hamano \n---\n Documentation/config.txt | 60 +++++++++++++++++++++++++++++-------------------\n 1 file changed, 37 insertions(+), 23 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 6b135be..ec852ab 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1515,30 +1515,44 @@ http.useragent::\n \n http..*::\n \tAny of the http.* options above can be applied selectively to some urls.\n-\tFor example \"http.https://example.com.useragent\" would set the user\n-\tagent only for https connections to example.com. The value\n-\tmatches a url if it refers to the same scheme, host and port and the\n-\tpath portion is an exact match or a prefix that matches at a \"/\"\n-\tboundary. If does not include a user name, it will match a url\n-\twith any username otherwise the user name must match as well (the\n-\tpassword part, if present in the url, is always ignored). A \n-\twith longer path matches takes precedence over shorter matches no matter\n-\twhat order they occur in the configuration file.\n+\tFor a config key to match a URL, each element of the config key is\n+\tcompared to that of the URL, in the following order:\n +\n-For example, if both \"https://user@example.com/path\" and\n-\"https://example.com/path/name\" are used as a config value and\n-then \"https://user@example.com/path/name/here\" is passed to a git\n-command, the settings in the \"https://example.com/path/name\" section\n-will be preferred because that has a longer path length match than\n-\"https://user@example.com/path\" even though the latter did match the\n-user. For same length matches, the last one wins except that a same\n-length match that includes a user name will be preferred over a\n-same length match that does not. The urls are normalized before\n-matching so that equivalent urls that are simply spelled differently\n-will match properly. Environment variable settings always override any\n-matches. The urls that are matched against are those given directly to\n-git commands. This means any urls visited as a result of a redirection\n-do not participate in matching.\n+--\n+. Scheme (e.g., `https` in `https://example.com/`). This field\n+ must match exactly between the config key and the URL.\n+. Host/domain name (e.g., `example.com` in `https://example.com/`).\n+ This field must match exactly between the config key and the URL.\n+. Port number (e.g., `8080` in `http://example.com:8080/`).\n+ This field must match exactly between the config key and the URL.\n+ Omitted port numbers are automatically converted to the correct\n+ default for the scheme before matching.\n+. Path (e.g., `repo.git` in `https://example.com/repo.git`). The\n+ path field of the config key must match the path field of the URL\n+ either exactly or as a prefix of slash-delimited path elements. This means\n+ a config key with path `foo/` matches URL path `foo/bar`. A prefix can only\n+ match on a slash (`/`) boundary. Longer matches take precedence (so a config\n+ key with path `foo/bar` is a better match to URL path `foo/bar` than a config\n+ key with just path `foo/`).\n+. Exact user name match (e.g., `user` in `https://user@example.com/repo.git`).\n+ If the config key has a user name it must match the user name in the URL\n+ exactly.\n+. Any user name match. If a config key does not have a user name, that config\n+ key will match a URL with any user name (including none).\n+--\n++\n+The list above is ordered by decreasing precedence; a URL that matches\n+a config key's path is preferred to one that matches its user name. For example,\n+if the URL is `https://user@example.com/foo/bar` a config key match of\n+`https://example.com/foo` will be preferred over a config key match of\n+`https://user@example.com`.\n++\n+All URLs are normalized before attempting any matching (the password part,\n+if embedded in the URL, is always ignored for matching purposes) so that\n+equivalent urls that are simply spelled differently will match properly.\n+Environment variable settings always override any matches. The urls that are\n+matched against are those given directly to Git commands. This means any URLs\n+visited as a result of a redirection do not participate in matching.\n \n i18n.commitEncoding::\n \tCharacter encoding the commit messages are stored in; Git itself\n-- \n1.8.4-rc0-117-gda13126\n"},{"id":"224108","messageId":"7vwqod3ld6.fsf@alter.siamese.dyndns.org","threadId":"34536","inReplyTo":"7v8v0t50kq.fsf@alter.siamese.dyndns.org","subject":"Re: [REQUEST 1/1] docs: update http..* options documentation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-26T06:07:17Z","receivedAt":"2013-07-26T06:07:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Will queue the attached, unless you spot glaring errors made by me,\n> coding while drunk ;-)\n\n... aaaaaand, it turns out that I screwed up while running \"git\ncommit --amend\" (missed \"-a\").\n\nI should go to bed now.\n\n-- >8 --\nFrom: \"Kyle J. McKay\" \nDate: Thu, 25 Jul 2013 15:39:13 -0700\nSubject: [PATCH] docs: update http..* options documentation\n\nOverhaul the text of the http..* options documentation\nproviding a hopefully easier to understand itemized list of matching\nbehavior as suggested by and including text from Jeff King.\n\nSigned-off-by: Jeff King \nSigned-off-by: Kyle J. McKay \nSigned-off-by: Junio C Hamano \n---\n Documentation/config.txt | 63 ++++++++++++++++++++++++++++++------------------\n 1 file changed, 40 insertions(+), 23 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 6b135be..60c140f 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1515,30 +1515,47 @@ http.useragent::\n \n http..*::\n \tAny of the http.* options above can be applied selectively to some urls.\n-\tFor example \"http.https://example.com.useragent\" would set the user\n-\tagent only for https connections to example.com. The value\n-\tmatches a url if it refers to the same scheme, host and port and the\n-\tpath portion is an exact match or a prefix that matches at a \"/\"\n-\tboundary. If does not include a user name, it will match a url\n-\twith any username otherwise the user name must match as well (the\n-\tpassword part, if present in the url, is always ignored). A \n-\twith longer path matches takes precedence over shorter matches no matter\n-\twhat order they occur in the configuration file.\n+\tFor a config key to match a URL, each element of the config key is\n+\tcompared to that of the URL, in the following order:\n +\n-For example, if both \"https://user@example.com/path\" and\n-\"https://example.com/path/name\" are used as a config value and\n-then \"https://user@example.com/path/name/here\" is passed to a git\n-command, the settings in the \"https://example.com/path/name\" section\n-will be preferred because that has a longer path length match than\n-\"https://user@example.com/path\" even though the latter did match the\n-user. For same length matches, the last one wins except that a same\n-length match that includes a user name will be preferred over a\n-same length match that does not. The urls are normalized before\n-matching so that equivalent urls that are simply spelled differently\n-will match properly. Environment variable settings always override any\n-matches. The urls that are matched against are those given directly to\n-git commands. This means any urls visited as a result of a redirection\n-do not participate in matching.\n+--\n+. Scheme (e.g., `https` in `https://example.com/`). This field\n+ must match exactly between the config key and the URL.\n+\n+. Host/domain name (e.g., `example.com` in `https://example.com/`).\n+ This field must match exactly between the config key and the URL.\n+\n+. Port number (e.g., `8080` in `http://example.com:8080/`).\n+ This field must match exactly between the config key and the URL.\n+ Omitted port numbers are automatically converted to the correct\n+ default for the scheme before matching.\n+\n+. Path (e.g., `repo.git` in `https://example.com/repo.git`). The\n+ path field of the config key must match the path field of the URL\n+ either exactly or as a prefix of slash-delimited path elements. This means\n+ a config key with path `foo/` matches URL path `foo/bar`. A prefix can only\n+ match on a slash (`/`) boundary. Longer matches take precedence (so a config\n+ key with path `foo/bar` is a better match to URL path `foo/bar` than a config\n+ key with just path `foo/`).\n+\n+. User name (e.g., `user` in `https://user@example.com/repo.git`). If\n+ the config key has a user name it must match the user name in the\n+ URL exactly. If the config key does not have a user name, that\n+ config key will match a URL with any user name (including none).\n+--\n++\n+The list above is ordered by decreasing precedence; a URL that matches\n+a config key's path is preferred to one that matches its user name. For example,\n+if the URL is `https://user@example.com/foo/bar` a config key match of\n+`https://example.com/foo` will be preferred over a config key match of\n+`https://user@example.com`.\n++\n+All URLs are normalized before attempting any matching (the password part,\n+if embedded in the URL, is always ignored for matching purposes) so that\n+equivalent urls that are simply spelled differently will match properly.\n+Environment variable settings always override any matches. The urls that are\n+matched against are those given directly to Git commands. This means any URLs\n+visited as a result of a redirection do not participate in matching.\n \n i18n.commitEncoding::\n \tCharacter encoding the commit messages are stored in; Git itself\n-- \n1.8.4-rc0-117-gda13126\n"},{"id":"224109","messageId":"0A68F4A5-22B0-4629-8693-73258566E218@gmail.com","threadId":"34536","inReplyTo":"20130726043748.GA20286@sigill.intra.peff.net","subject":"Re: [REQUEST 1/1] docs: update http..* options documentation","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2013-07-26T06:23:23Z","receivedAt":"2013-07-26T06:23:23Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Jul 25, 2013, at 21:37, Jeff King wrote:\n> On Thu, Jul 25, 2013 at 03:39:13PM -0700, Kyle J. McKay wrote:\n>\n>> Overhaul the text of the http..* options documentation\n>> providing a hopefully easier to understand itemized list of\n>> matching behavior as suggested by and including text from\n>> Jeff King.\n>> ---\n>\n> Signed-off-by: Jeff King \n\nThank you. Added.\n\n> You should add your S-O-B, too, for your bits.\n\nYes. I wanted to make certain it didn't get applied just yet. :)\n\n>> +--\n>> +. Scheme (e.g., `https` in `https://example.com/`). This field\n>> + must match exactly between the config key and the URL.\n>> +. Host/domain name (e.g., `example.com` in `https://example.com/`).\n>> + This field must match exactly between the config key and the URL.\n>\n> These look fine in the rendered manpage, but I think the source \n> might be\n> a little easier to read with a blank line between items.\n\nMy ASCIIDOC is a bit weak. I have added some blank lines.\n\n>> +. Exact user name match (e.g., `user` in `https://user@example.com/repo.git \n>> `).\n>> + If the config key has a user name it must match the user name in \n>> the URL\n>> + exactly.\n>> +. Any user name match. If a config key does not have a user name, \n>> that config\n>> + key will match a URL with any user name (including none).\n>\n> IMHO, this would be more clear as a single item, like:\n>\n> . User name (e.g., `user` in `https://user@example.com/repo.git`). If\n> the config key has a user name it must match the user name in the\n> URL exactly. If the config key does not have a user name, that\n> config key will match a URL with any user name (including none).\n\nThe only problem I have with a single item is what's the precedence? \nDoes an exact user match have the same precedence as an any-user \nmatch? That would seem to be implied by having them as the same item \nnumber. Separating them would appear to make it clearer that an exact \nuser match wins over an any user match, but if you have some alternate \ntext as a suggestion for the single item that clears that up... :)\n\n>> +All URLs are normalized before attempting any matching (the \n>> password part,\n>> +if embedded in the URL, is always ignored for matching purposes) \n>> so that\n>> +equivalent urls that are simply spelled differently will match \n>> properly.\n>\n> And this nicely ties up the open questions I had after re-reading the\n> list. Good.\n>\n> We could define \"equivalent\" here (the %-encoding thing is obvious, I\n> think, but which components are case-sensitive and which are not is\n> perhaps a bit subtle). I do not necessarily know that it is useful to\n> the user, though, and is one more thing to confuse them. And somebody\n> who really cares can look at the appropriate RFCs.\n\nI am considering this text to address that:\n\n> All URLs are normalized (%-encodings are standardized, case- \n> insensitive\n> parts are lowercased, `./` and `../` path components are resolved) \n> before\n> attempting any matching (the password part, if embedded in the URL,\n\nbut I'm not sure the extra verbiage makes it better. I think it may \njust complicate the explanation unnecessarily?\n"},{"id":"224110","messageId":"C8089D89-160D-4769-9E99-04FE310805AA@gmail.com","threadId":"34536","inReplyTo":"20130726043748.GA20286@sigill.intra.peff.net","subject":"Re: [REQUEST 1/1] docs: update http..* options documentation","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2013-07-26T06:42:10Z","receivedAt":"2013-07-26T06:42:10Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Jul 25, 2013, at 23:23, Kyle J. McKay wrote:\n> On Jul 25, 2013, at 21:37, Jeff King wrote:\n>> You should add your S-O-B, too, for your bits.\n>\n> Yes. I wanted to make certain it didn't get applied just yet. :)\n\nLooks like it got patch snarfed anyway. ;-)\n\nOn Jul 25, 2013, at 23:07, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> Will queue the attached, unless you spot glaring errors made by me,\n>> coding while drunk ;-)\n\nOn Jul 25, 2013, at 21:37, Jeff King wrote:\n> So this patch looks pretty good to me; the two points I raised above \n> are\n> how I would have done it, but they are relatively minor if you do not\n> agree.\n\nSo Yeah, looks pretty good to me too then. ;)\n"},{"id":"224151","messageId":"20130726222732.GA3444@sigill.intra.peff.net","threadId":"34536","inReplyTo":"0A68F4A5-22B0-4629-8693-73258566E218@gmail.com","subject":"Re: [REQUEST 1/1] docs: update http..* options documentation","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-07-26T22:27:32Z","receivedAt":"2013-07-26T22:27:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jul 25, 2013 at 11:23:23PM -0700, Kyle J. McKay wrote:\n\n> >IMHO, this would be more clear as a single item, like:\n> >\n> > . User name (e.g., `user` in `https://user@example.com/repo.git`). If\n> > the config key has a user name it must match the user name in the\n> > URL exactly. If the config key does not have a user name, that\n> > config key will match a URL with any user name (including none).\n> \n> The only problem I have with a single item is what's the precedence?\n> Does an exact user match have the same precedence as an any-user\n> match? That would seem to be implied by having them as the same item\n> number. Separating them would appear to make it clearer that an\n> exact user match wins over an any user match, but if you have some\n> alternate text as a suggestion for the single item that clears that\n> up... :)\n\nAh, I see your thinking now. You want to say \"no username has less\nprecedence than some username, which has less precedence than a path\",\nso they are all elements of a single list. My thinking was \"username\nhas precedence less than path, and like a shorter path has less\nprecedence than a longer path, an empty username has less precedence\nthan a non-empty username\".\n\nI agree my suggested wording would need to mention that explicitly.\nLike:\n\n . User name (e.g., `user` in `https://user@example.com/repo.git`). If\n the config key has a user name it must match the user name in the\n URL exactly. If the config key does not have a user name, that\n config key will match a URL with any user name (including none), but\n at lower precedence than a config key with a user name.\n\nI can live with it either way, though. They are just two ways of\nconsidering the same thing.\n\n> I am considering this text to address that:\n> \n> >All URLs are normalized (%-encodings are standardized, case-insensitive\n> >parts are lowercased, `./` and `../` path components are resolved)\n> >before\n> >attempting any matching (the password part, if embedded in the URL,\n> \n> but I'm not sure the extra verbiage makes it better. I think it may\n> just complicate the explanation unnecessarily?\n\nYeah, I think I agree. Let's leave it out.\n\n-Peff\n"},{"id":"224163","messageId":"251106F7-56FA-4503-A4C9-267A5EF04A2C@gmail.com","threadId":"34536","inReplyTo":"20130726222732.GA3444@sigill.intra.peff.net","subject":"Re: [REQUEST 1/1] docs: update http..* options documentation","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2013-07-27T02:15:07Z","receivedAt":"2013-07-27T02:15:07Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Jul 26, 2013, at 15:27, Jeff King wrote:\n\n> On Thu, Jul 25, 2013 at 11:23:23PM -0700, Kyle J. McKay wrote:\n>\n>>> IMHO, this would be more clear as a single item, like:\n>>>\n>>> . User name (e.g., `user` in `https://user@example.com/repo.git`). \n>>> If\n>>> the config key has a user name it must match the user name in the\n>>> URL exactly. If the config key does not have a user name, that\n>>> config key will match a URL with any user name (including none).\n>>\n>> The only problem I have with a single item is what's the precedence?\n>> Does an exact user match have the same precedence as an any-user\n>> match? That would seem to be implied by having them as the same item\n>> number. Separating them would appear to make it clearer that an\n>> exact user match wins over an any user match, but if you have some\n>> alternate text as a suggestion for the single item that clears that\n>> up... :)\n>\n> Ah, I see your thinking now. You want to say \"no username has less\n> precedence than some username, which has less precedence than a path\",\n> so they are all elements of a single list. My thinking was \"username\n> has precedence less than path, and like a shorter path has less\n> precedence than a longer path, an empty username has less precedence\n> than a non-empty username\".\n>\n> I agree my suggested wording would need to mention that explicitly.\n> Like:\n>\n> . User name (e.g., `user` in `https://user@example.com/repo.git`). If\n> the config key has a user name it must match the user name in the\n> URL exactly. If the config key does not have a user name, that\n> config key will match a URL with any user name (including none), \n> but\n> at lower precedence than a config key with a user name.\n>\n> I can live with it either way, though. They are just two ways of\n> considering the same thing.\n>\n>> I am considering this text to address that:\n>>\n>>> All URLs are normalized (%-encodings are standardized, case- \n>>> insensitive\n>>> parts are lowercased, `./` and `../` path components are resolved)\n>>> before\n>>> attempting any matching (the password part, if embedded in the URL,\n>>\n>> but I'm not sure the extra verbiage makes it better. I think it may\n>> just complicate the explanation unnecessarily?\n>\n> Yeah, I think I agree. Let's leave it out.\n\nSo there's a version of this in next as cea9928 and I think that \nversion is fine. If the documentation gets updated in the future, or \nperhaps moved to a separate urls-matching.txt for some reason at some \npoint (git config --url, git config --url-parse), I'll make a point of \ninserting the \", but at lower precedence than a config key with a user \nname\" text.\n\nKyle\n"},{"id":"224164","messageId":"20130727024353.GA19853@sigill.intra.peff.net","threadId":"34536","inReplyTo":"251106F7-56FA-4503-A4C9-267A5EF04A2C@gmail.com","subject":"Re: [REQUEST 1/1] docs: update http..* options documentation","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-07-27T02:43:53Z","receivedAt":"2013-07-27T02:43:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 26, 2013 at 07:15:07PM -0700, Kyle J. McKay wrote:\n\n> So there's a version of this in next as cea9928 and I think that\n> version is fine. If the documentation gets updated in the future, or\n> perhaps moved to a separate urls-matching.txt for some reason at some\n> point (git config --url, git config --url-parse), I'll make a point\n> of inserting the \", but at lower precedence than a config key with a\n> user name\" text.\n\nUnless you are planning to do that immediately, we are very likely to\nforget. Either it is worth adding or not, and if it is, we should not\nlet having to add one more commit stop us.\n\nHere it is in patch form, so the amount of effort does not influence our\ndecision. :)\n\nI'd lean towards including it, but don't feel strongly.\n\n-- >8 --\nSubject: [PATCH] docs: mention precedence of empty username matching in URLs\n\nThe documentation makes it clear that a URL with a username\nwill match a config entry with or without a username, but is\nnot clear that in the presence of both, the one with\nusername would be preferred.\n\nSigned-off-by: Jeff King \n---\n Documentation/config.txt | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 0dd5566..f2ed9ef 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1568,7 +1568,8 @@ http..*::\n . User name (e.g., `user` in `https://user@example.com/repo.git`). If\n the config key has a user name it must match the user name in the\n URL exactly. If the config key does not have a user name, that\n- config key will match a URL with any user name (including none).\n+ config key will match a URL with any user name (including none),\n+ but at a lower precedence than a config key with a user name.\n --\n +\n The list above is ordered by decreasing precedence; a URL that matches\n-- \n1.8.3.rc1.30.gff0fb75\n"},{"id":"224165","messageId":"C0FA1DEA-A725-40B4-AE9D-5F49B61C94BC@gmail.com","threadId":"34536","inReplyTo":"20130727024353.GA19853@sigill.intra.peff.net","subject":"Re: [REQUEST 1/1] docs: update http..* options documentation","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2013-07-27T03:04:53Z","receivedAt":"2013-07-27T03:04:53Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Jul 26, 2013, at 19:43, Jeff King wrote:\n> On Fri, Jul 26, 2013 at 07:15:07PM -0700, Kyle J. McKay wrote:\n>\n>> So there's a version of this in next as cea9928 and I think that\n>> version is fine. If the documentation gets updated in the future, or\n>> perhaps moved to a separate urls-matching.txt for some reason at some\n>> point (git config --url, git config --url-parse), I'll make a point\n>> of inserting the \", but at lower precedence than a config key with a\n>> user name\" text.\n>\n> Unless you are planning to do that immediately, we are very likely to\n> forget. Either it is worth adding or not, and if it is, we should not\n> let having to add one more commit stop us.\n>\n> Here it is in patch form, so the amount of effort does not influence \n> our\n> decision. :)\n>\n> I'd lean towards including it, but don't feel strongly.\n>\n> -- >8 --\n> Subject: [PATCH] docs: mention precedence of empty username matching \n> in URLs\n>\n> The documentation makes it clear that a URL with a username\n> will match a config entry with or without a username, but is\n> not clear that in the presence of both, the one with\n> username would be preferred.\n>\n> Signed-off-by: Jeff King \n> ---\n> Documentation/config.txt | 3 ++-\n> 1 file changed, 2 insertions(+), 1 deletion(-)\n>\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 0dd5566..f2ed9ef 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -1568,7 +1568,8 @@ http..*::\n> . User name (e.g., `user` in `https://user@example.com/repo.git`). If\n> the config key has a user name it must match the user name in the\n> URL exactly. If the config key does not have a user name, that\n> - config key will match a URL with any user name (including none).\n> + config key will match a URL with any user name (including none),\n> + but at a lower precedence than a config key with a user name.\n> --\n> +\n> The list above is ordered by decreasing precedence; a URL that matches\n> -- \n> 1.8.3.rc1.30.gff0fb75\n>\n\nI like it. :)\n\n+1 for adding it as an incremental patch to next.\n"}]}