Jeff King <> writes:

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

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 ;-)
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to