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]

 



On Mon, Jul 22, 2013 at 05:56:43AM -0700, Kyle J. McKay wrote:

> In order to perform sane URL matching for http.<url>.* options,
> http.c normalizes URLs before performing matches.
> 
> A new test-url-normalize test program is introduced along with
> a new t5200-url-normalize.sh script to run the tests.

While looking at test-url-normalize (and wanting to experiment some with
your series to see how it handled a few behaviors), I wondered if we
shouldn't be exposing this selection process to the user somehow via
git-config.

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.

If we want to go that route, we don't have to do it now (the test-*
interface is unpublished, and the git-config interface can simply come
later than the internal feature).  But it may be worth thinking about
now while it is in your head.

> diff --git a/test-url-normalize.c b/test-url-normalize.c
> new file mode 100644
> index 0000000..f18bd88
> --- /dev/null
> +++ b/test-url-normalize.c
> [...]
> +	if (!strcmp("sslverify", opt_lc.buf))
> +		printf("%s\n", curl_ssl_verify ? "true" : "false");
> +	else if (!strcmp("sslcert", opt_lc.buf))
> +		printf("%s\n", ssl_cert);
> +#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)?

> +#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?

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