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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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@xxxxxxxxxxx/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@xxxxxxxxxxx/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.

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
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]