git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "Kyle J. McKay" <mackyle@gmail.com>
Cc: git@vger.kernel.org, "David Aguilar" <davvid@gmail.com>,
	"Petr Baudis" <pasky@ucw.cz>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Richard Hartmann" <richih.mailinglist@gmail.com>,
	"Daniel Knittl-Frank" <knittl89@googlemail.com>,
	"Jan Krüger" <jk@jk.gs>, "Alejandro Mery" <amery@geeks.cl>,
	"Aaron Schrab" <aaron@schrab.com>,
	"Eric Sunshine" <sunshine@sunshineco.com>
Subject: Re: [PATCH v8 3/4] tests: add new test for the url_normalize function
Date: Wed, 24 Jul 2013 02:59:33 -0400	[thread overview]
Message-ID: <20130724065933.GC30074@sigill.intra.peff.net> (raw)
In-Reply-To: <60d85be89d27515d913ae15e10c332f@f74d39fa044aa309eaea14b9f57fe79>

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

  reply	other threads:[~2013-07-24  6:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-22 12:56 [PATCH v8 0/4] config: add support for http.<url>.* settings Kyle J. McKay
2013-07-22 12:56 ` [PATCH v8 1/4] " Kyle J. McKay
2013-07-24  7:12   ` Jeff King
2013-07-22 12:56 ` [PATCH v8 2/4] config: improve " Kyle J. McKay
2013-07-22 12:56 ` [PATCH v8 3/4] tests: add new test for the url_normalize function Kyle J. McKay
2013-07-24  6:59   ` Jeff King [this message]
2013-07-24 17:14     ` Junio C Hamano
2013-07-24 18:43       ` Kyle J. McKay
2013-07-24 19:01     ` Kyle J. McKay
2013-07-24 19:03       ` Jeff King
2013-07-22 12:56 ` [PATCH v8 4/4] config: allow http.<url>.* any user matching Kyle J. McKay
2013-07-22 18:00   ` Junio C Hamano
2013-07-22 20:24     ` Kyle J. McKay
2013-07-22 21:51       ` Junio C Hamano
2013-07-22 22:18         ` Kyle J. McKay
2013-07-22 22:34           ` Junio C Hamano
2013-07-24  6:42       ` Jeff King
2013-07-24 15:00         ` Junio C Hamano
2013-07-24  6:44   ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130724065933.GC30074@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=aaron@schrab.com \
    --cc=amery@geeks.cl \
    --cc=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jk@jk.gs \
    --cc=knittl89@googlemail.com \
    --cc=mackyle@gmail.com \
    --cc=pasky@ucw.cz \
    --cc=richih.mailinglist@gmail.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).