(I'm attempting to combine the various separate email replies into a
single response here, please forgive me if I mangle something up.)
On Jul 14, 2013, at 22:12, Jeff King wrote:
On Sun, Jul 14, 2013 at 09:02:19PM -0700, Junio C Hamano wrote:
Or proceed with what's there right now (there
Kyle J. McKay mack...@gmail.com writes:
On Jul 12, 2013, at 13:58, Aaron Schrab wrote:
...
This should guarantee a match in the scenario Aaron proposes above and
still has pretty much the same easy explanation to the user.
Shall I go ahead and add that to the next patch version?
Or
On Fri, Jul 12, 2013 at 06:07:35AM -0700, Kyle J. McKay wrote:
It looks like you're matching the URLs as raw strings, and I don't see
any canonicalization going on. What happens if I have
https://example.com/foo+bar; in my config, but then I visit
https://example.comfoo%20bar;?
The
On Sat, Jul 13, 2013 at 12:46:17PM -0700, Kyle J. McKay wrote:
I expect it will be easier just to normalize the URL without
splitting. That is, lowercase the parts that are case-insensitive
(scheme and host name) and adjust the URL-escaping to remove URL
escaping (%xx) from characters that
On Sun, Jul 14, 2013 at 09:02:19PM -0700, Junio C Hamano wrote:
Or proceed with what's there right now (there are a few pending
updates from reviewers) and then, as Junio says above, adjust it later
if needed?
I have been assuming that strictly textual match will be a subset
of the
On Jul 12, 2013, at 13:58, Aaron Schrab wrote:
At 06:07 -0700 12 Jul 2013, Kyle J. McKay mack...@gmail.com wrote:
I don't think it's necessary to split the URL apart though.
Whatever URL the user gave to git on the command line (at some
point even if it's now stored as a remote setting in
On Thu, Jul 11, 2013 at 02:50:03PM -0700, Kyle J. McKay wrote:
The url value is considered a match to a url if the url value
is either an exact match or a prefix of the url which ends on a
path component boundary ('/'). So https://example.com/test; will
match https://example.com/test; and
On Jul 12, 2013, at 02:59, Jeff King wrote:
On Thu, Jul 11, 2013 at 02:50:03PM -0700, Kyle J. McKay wrote:
A few comments on the implementation:
+enum http_option_type {
+ opt_post_buffer = 0,
+ opt_min_sessions,
We usually put enum fields in ALL_CAPS to mark them as constants
At 06:07 -0700 12 Jul 2013, Kyle J. McKay mack...@gmail.com wrote:
I don't think it's necessary to split the URL apart though. Whatever
URL the user gave to git on the command line (at some point even if
it's now stored as a remote setting in config) complete with URL-
encoding, user names,
The url value is considered a match to a url if the url value
is either an exact match or a prefix of the url which ends on a
path component boundary ('/'). So https://example.com/test; will
match https://example.com/test; and https://example.com/test/too;
but not https://example.com/testextra;.
Kyle J. McKay mack...@gmail.com writes:
+static size_t http_option_max_matched_len[opt_max];
+
static int curl_ssl_verify = -1;
static int curl_ssl_try;
static const char *ssl_cert;
@@ -141,34 +169,122 @@ static void process_curl_messages(void)
}
#endif
+static size_t
11 matches
Mail list logo
