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

From: Jeff King <peff@peff.net>
Date: Jul 15, 2013, 05:12 UTC
Message-ID: <20130715051233.GC21127@sigill.intra.peff.net>
In-Reply-To: <7v8v18fp2s.fsf@alter.siamese.dyndns.org>

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

Show 13 quoted lines

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