On Jul 24, 2013, at 10:14, Junio C Hamano wrote:
Jeff King <peff@xxxxxxxx> writes:
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.
Lovely.
[snip]
Another thing we may want to consider is to see if we can
restructure the http_options interface a bit, so that the caller can
be agonistic to the actual meaning of the key. For example,
"git config --url http notknownyet $URL"
may want to be able to show the value for http.<pattern>.notknownyet
for the most matching <pattern> for a given $URL, without knowing
what the variable means, just like any other configuration that is
queried via the "git config" program. The caller may want to pass
further type information like --bool, --int and --path as needed.
+#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?
Probably not.
It's a hint that the name of the function might change. If it's going
to be used in a more generic fashion it may not belong in http.c
anymore in which case the name will likely change along with the
location. Nothing about the normalization function requires CURL or
http/https, so it would work equally well on rsync, ftp, smtp etc.
urls and could just move into url.{h,c} as url_normalize.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html