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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> That is, would a shell script ever want to say "what is the value of
> this config variable for url $X"? Certainly our test scripts want to,
> and having a test-* program covers that, but might user scripts want to
> do the same? Or even to introduce its own URL-matched config options?
>
> 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.

>> +#if LIBCURL_VERSION_NUM >= 0x070903
>> +	else if (!strcmp("sslkey", opt_lc.buf))
>> +		printf("%s\n", ssl_key);
>> +#endif
>> +#if LIBCURL_VERSION_NUM >= 0x070908
>> +	else if (!strcmp("sslcapath", opt_lc.buf))
>> +		printf("%s\n", ssl_capath);
>> +#endif
>> [...]
>
> Do we need to have the complete list of options here, including curl
> version limitations? It seems like this will eventually get out of date
> with the list of options. Would it be sufficient to test just one (or
> even just handle a fake "http.$URL.foo" variable)?

Yeah, and that will be in line with "git config --url" direction.

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.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]