Re: [PATCH v8 3/4] tests: add new test for the url_normalize function

["Kyle J. McKay" <mackyle@gmail.com>]

On Jul 24, 2013, at 10:14, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
>> How hard would it be to convert the "-c" option of test-url-normalize
>> into something like:
>>
>>  git config --file=foo --url http noepsv $URL
>>
>> which would look for http.$URL.noepsv matches.
>
> Lovely.

[snip]

> Another thing we may want to consider is to see if we can
> restructure the http_options interface a bit, so that the caller can
> be agonistic to the actual meaning of the key.  For example,
>
>  "git config --url http notknownyet $URL"
>
> may want to be able to show the value for http.<pattern>.notknownyet
> for the most matching <pattern> for a given $URL, without knowing
> what the variable means, just like any other configuration that is
> queried via the "git config" program.  The caller may want to pass
> further type information like --bool, --int and --path as needed.
>
>>> +#define url_normalize(u) http_options_url_normalize(u)
>>
>> Does this macro do anything besides shorten the name? Is the extra
>> level of indirection to the reader worth it?
>
> Probably not.

It's a hint that the name of the function might change.  If it's going  
to be used in a more generic fashion it may not belong in http.c  
anymore in which case the name will likely change along with the  
location.  Nothing about the normalization function requires CURL or  
http/https, so it would work equally well on rsync, ftp, smtp etc.  
urls and could just move into url.{h,c} as url_normalize.