On Mon, Jul 22, 2013 at 05:56:41AM -0700, Kyle J. McKay wrote:
> +enum http_option_type {
> + OPT_POST_BUFFER,
> + OPT_MIN_SESSIONS,
> + OPT_SSL_VERIFY,
> + OPT_SSL_TRY,
> + OPT_SSL_CERT,
> + OPT_SSL_CAINFO,
> + OPT_LOW_SPEED,
> + OPT_LOW_TIME,
> + OPT_NO_EPSV,
> + OPT_HTTP_PROXY,
> + OPT_COOKIE_FILE,
> + OPT_USER_AGENT,
> + OPT_PASSWD_REQ,
> +#ifdef USE_CURL_MULTI
> + OPT_MAX_REQUESTS,
> +#endif
> +#if LIBCURL_VERSION_NUM >= 0x070903
> + OPT_SSL_KEY,
> +#endif
> +#if LIBCURL_VERSION_NUM >= 0x070908
> + OPT_SSL_CAPATH,
> +#endif
> + OPT_MAX
> +};
> +
> +static size_t http_option_max_matched_len[OPT_MAX];
It's frustrating that we now have an extra spot to add new options to
(e.g., somebody else is adding http.savecookies in another thread, and
the merge will need to not just resolve the textual conflicts, but add
it to this other list).
Might it be simpler to just keep a dynamic list indexed by option name
(either a hash table, or a sorted string_list)? We only incur a lookup
when we find an actual config entry, so the number of lookups (and
entries) should be minuscule and not affect performance. And as a bonus,
it lets us handle arbitrary keys if we want to allow "git config" to
learn about url matching for user-specified keys.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
