Re: [REQUEST 1/1] docs: update http.<url>.* options documentation

> On Thu, Jul 25, 2013 at 11:23:23PM -0700, Kyle J. McKay wrote:
>
>>> IMHO, this would be more clear as a single item, like:
>>>
>>> . User name (e.g., `user` in `https://user@example.com/repo.git`).  
>>> If
>>>  the config key has a user name it must match the user name in the
>>>  URL exactly. If the config key does not have a user name, that
>>>  config key will match a URL with any user name (including none).
>>
>> The only problem I have with a single item is what's the precedence?
>> Does an exact user match have the same precedence as an any-user
>> match?  That would seem to be implied by having them as the same item
>> number.  Separating them would appear to make it clearer that an
>> exact user match wins over an any user match, but if you have some
>> alternate text as a suggestion for the single item that clears that
>> up...  :)
>
> Ah, I see your thinking now. You want to say "no username has less
> precedence than some username, which has less precedence than a path",
> so they are all elements of a single list.  My thinking was "username
> has precedence less than path, and like a shorter path has less
> precedence than a longer path, an empty username has less precedence
> than a non-empty username".
>
> I agree my suggested wording would need to mention that explicitly.
> Like:
>
>  . User name (e.g., `user` in `https://user@example.com/repo.git`). If
>    the config key has a user name it must match the user name in the
>    URL exactly. If the config key does not have a user name, that
>    config key will match a URL with any user name (including none),  
> but
>    at lower precedence than a config key with a user name.
>
> I can live with it either way, though. They are just two ways of
> considering the same thing.
>
>> I am considering this text to address that:
>>
>>> All URLs are normalized (%-encodings are standardized, case- 
>>> insensitive
>>> parts are lowercased, `./` and `../` path components are resolved)
>>> before
>>> attempting any matching (the password part, if embedded in the URL,
>>
>> but I'm not sure the extra verbiage makes it better.  I think it may
>> just complicate the explanation unnecessarily?
>
> Yeah, I think I agree. Let's leave it out.