Re: [PATCH v3] config: add support for http.<url>.* settings

On Sun, Jul 14, 2013 at 09:02:19PM -0700, Junio C Hamano wrote:

quoted

Or proceed with what's there right now (there are a few pending
updates from reviewers) and then, as Junio says above, adjust it later
if needed?

I have been assuming that "strictly textual match" will be a subset
of the matching semantics Aaron and Peff suggested.  That is, if we
include your version in the upcoming release, the user writes the
http.<URLpattern>.<variable> configuration so that the entries match
what they want them to match, the enhanced URL matcher Aaron and
Peff suggested will still make them match.

Am I mistaken?  Will there be some <URLpattern> that will not match
with the same URL literally?

I think we need to decide now, because the two schemes are not
compatible, and switching will break setups. Yes, the matcher that Aaron
and I suggest is a strict superset (i.e., we will not stop matching
things that used to match), which is good. But we would not be able to
implement "longest prefix wins" overriding anymore, which would change
the meaning of cases like:

  [http "https://example.com"] foo = 1
  [http] foo = 2

(under Kyle's scheme it is "1", and under ours "2"). We can probably
come up with some clever rules for overriding a broken-down URL that
would stay backwards compatible. E.g., longest-prefix-match if there are
no wildcarded components, and last-one-wins if there are. But that is
not a rule I would want readers to have to puzzle out in the
documentation.

So I think we are much better off to decide the semantics now.

-Peff