git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "Kyle J. McKay" <mackyle@gmail.com>
Subject: Re: [PATCH 3/3] config: --get-urlmatch
Date: Mon, 29 Jul 2013 17:37:16 -0700	[thread overview]
Message-ID: <20130730003716.GA13114@sigill.intra.peff.net> (raw)
In-Reply-To: <1375138150-19520-4-git-send-email-gitster@pobox.com>

On Mon, Jul 29, 2013 at 03:49:10PM -0700, Junio C Hamano wrote:

> "git config --get-urlmatch $section[.$variable] $url" is a way to
> learn what the configured value for $section.$variable is for the
> given URL, using the logic introduced by the http.<url>.config
> topic.

That interface looks good to me. It matches the --get-all/--get-regexp
options of git-config. It does not quite match --get-color, which is
really a type (like --bool or --int), but I think --get-color is the odd
one out there.

> This can still be further refactored to remove code from http_options()
> in http.c, I think.

Yeah, that would be the ultimate goal. I think you would just need to
keep the same string_list there, with one urlmatch_item per key that we
care about.

> ---
>  builtin/config.c | 141 +++++++++++++++++++++++++++++++++++++++++++++++++++++++

It seems like some of the logic here should be reusable for http.c.
Should it be in config.c instead?

> +struct urlmatch_collect {
> +	struct string_list vars;
> +	struct url_info url;
> +	const char *section;
> +	const char *key;
> +};
> +
> +struct urlmatch_item {
> +	size_t max_matched_len;
> +	char user_matched;
> +	char value_is_null;
> +	struct strbuf value;
> +};

I think you ultimately want such a string_list for matching arbitrary
numbers of keys, but do you need it for the git-config case?

You will always be matching collect->key, so you will only ever insert a
single item into the collect->vars list. IOW, this could be:

  struct urlmatch_collect {
    struct url_info url;
    const char *section;
    const char *key;
    struct urlmatch_item match;
  };

I don't mind if it is more complicated than this single-case needs to be
if the code is also being used to http.c, but I haven't seen that yet
(and this code would not used as-is, as you would want to call the
function with many potential collect->key values, but without
re-normalizing the URL over and over).

And of course, it needs docs and tests. :) The latter can probably come
by converting some of the test-url-normalize tests to just use
git-config instead.

-Peff

  reply	other threads:[~2013-07-30  0:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-24 19:07 [PATCH] test-url-normalize.c: Fix gcc errors and sparse warnings Ramsay Jones
2013-07-24 19:35 ` Kyle J. McKay
2013-07-24 20:39   ` Junio C Hamano
2013-07-29 22:49     ` [PATCH 0/3] "git config --get-urlmatch $section.$key $url" Junio C Hamano
2013-07-29 22:49       ` [PATCH 1/3] url-match: split out URL matching logic out of http.c Junio C Hamano
2013-07-29 22:49       ` [PATCH 2/3] builtin/config: refactor collect_config() Junio C Hamano
2013-07-29 22:49       ` [PATCH 3/3] config: --get-urlmatch Junio C Hamano
2013-07-30  0:37         ` Jeff King [this message]
2013-07-30  1:33           ` Junio C Hamano
2013-07-30  8:14             ` Jeff King
2013-07-30 13:52               ` Junio C Hamano
2013-07-30 19:14         ` Kyle J. McKay
2013-07-30  2:03       ` [PATCH 4/3] url-match: generalize configuration collection logic Junio C Hamano
2013-07-30  2:13         ` [PATCH 5/3] revert most of the http_options() change Junio C Hamano
2013-07-30 19:14           ` Kyle J. McKay
2013-07-30 19:41             ` Kyle J. McKay
2013-07-30 21:09               ` Junio C Hamano
2013-07-31 17:59       ` [PATCH 0/3] "git config --get-urlmatch $section.$key $url" Ramsay Jones
2013-07-31 19:31         ` Junio C Hamano

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=20130730003716.GA13114@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mackyle@gmail.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).