Re: [PATCH v8 4/4] config: allow http.<url>.* any user matching

Jeff King [off-list ref] writes:

  1. The explanation and special-casing of username is a little
     complicated to explain.

  2. The behavior for resolving the value when faced with multiple
     possibilities is completely unlike the rest of the config system
     (both dropping last-one-wins, and unlike the URL matching for
     credentials).

I think we can decide that (2) is worth it if your semantics are more
flexible in practice. It would be nice to see real-world feedback on how
people use it before setting the behavior in stone, but there's sort of
a chicken and egg problem there.

For (1), I wonder if the explanation would be simpler if the precedences
of each sub-part were simply laid out. That is, would it be correct to
say something like:

  For a config key to match a URL, each element of the config key (if
  present) is compared to that of the URL, in the following order:

    1. Protocol (e.g., `https` in `https://example.com/`). This field
       must match exactly between the config key and the URL.

    2. Host/domain name (e.g., `example.com` in `https://example.com/`).
       This field must match exactly between the config key and the URL.

    3. Path (e.g., `repo.git` in `https://example.com/repo.git`). This
       field is prefix-matched by slash-delimited path elements, so that
       config key `foo/` matches URL `foo/bar`. Longer matches take
       precedence (so `foo/bar`, if it exists, is a better match than
       just `foo/`).

    4. Username (e.g., `user` in `https://user@example.com/repo.git`).

  The list above is ordered by decreasing precedence; a URL that matches
  a config key's path is preferred to one that matches its username.

I don't know if that is more or less clear of an explanation. It makes
more sense to me, but that is probably because I wrote it. 

The above reads very clearly to me, too.  We may want to add that
the Username, if exists on the configuration key name, must match
exactly to the one in the URL the variable is queried for
(i.e. anonymous requests never match configuration for a specific
user).