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

On Jul 26, 2013, at 15:27, Jeff King wrote:

On Thu, Jul 25, 2013 at 11:23:23PM -0700, Kyle J. McKay wrote:

quoted

quoted

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.

quoted

I am considering this text to address that:

quoted

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.

So there's a version of this in next as cea9928 and I think that  
version is fine.  If the documentation gets updated in the future, or  
perhaps moved to a separate urls-matching.txt for some reason at some  
point (git config --url, git config --url-parse), I'll make a point of  
inserting the ", but at lower precedence than a config key with a user  
name" text.

Kyle