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

[Jeff King <peff@peff.net>]

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

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