Re: [PATCH 3/3] config: --get-urlmatch

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH 3/3] config: --get-urlmatch

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:58:16

Jeff King [off-list ref] writes:
quoted
+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?
"git config" does not know the semantics of each key, nor available
set of keys, no?  The string-list is only to support

    git config --get-urlmatch http http://www.google.com/

i.e. "list everything under http.* hierarchy".

And unlike http_option() which can incrementally always call back
the setter (and let it override older value), the command has to
read everything through and then give us the final value, so I do
not think we can get away without one.
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
That is in the works, of course ;-)

Re: [PATCH 3/3] config: --get-urlmatch

From: Jeff King <hidden>
Date: 2016-06-15 22:58:16

On Mon, Jul 29, 2013 at 06:33:43PM -0700, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
quoted
+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?
"git config" does not know the semantics of each key, nor available
set of keys, no?  The string-list is only to support

    git config --get-urlmatch http http://www.google.com/

i.e. "list everything under http.* hierarchy".
Ah, I missed that you could leave "key" empty. I had expected
collect->key to be filled in, at which point you only ever have one such
key (and you do not need to know the semantics, only which one is the
"winner").

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help