Junio, Just spent about 30 minutes replying to your points until the last one made most moot. I agree that putting the info into the url will fix the bug, which I have never seen (see #3 below), and make the howto easier to read. So a few things I wanted to discuss or ask for help on: 1) Note that I'm not a C guy so: Junio wrote: >> +static const char *curl_http_username = NULL; >> +static const char *curl_http_password = NULL; >> + > Please do not introduce new initializations of static variables to 0 or > NULL. As a clean-up, before your patch, you can send in a patch to fix > existing such initializations. I'm not sure what you mean here. Should I just declare them as: static const char *curl_http_password; ? Also do you mean that during after the patch phase they get changed to: static const char *curl_http_password = NULL; ? Or do you mean that I can send in a patch to fix other static variables (not mine) which are being initialized to NULL? 2) Being that I'm not a big C guy, I'm not sure the best way to go about parsing the username out of the URL to pull it into a variable to pass to CURLOPT_USERPASS. Any advice from the community would be greatly appreciated. 3) From my experience with curl, many of the options do not work the same across versions or platforms. For example, the new CURLOPT_USERNAME/PASSWORD options worked fine in 7.19.4 on cygwin but not on FC9, which is why I used the older USERPWD. Also, my curl never prompted me for the password when I supplied a username in the URL which is what prompted me to do this patch in the first place. As such, I think it is better to pull the username & password prompting logic into git make this stable and fix the bug. 4) I'm not really impressed that file permissions actually make the .netrc file a secure option. However, it's already in there and would break backwards compatibility to take it out. I also realize that there is a need for automated builds to be able to pull the source. So I would like to add a nice warning section to the http docs explaining the repercussions of using it. Thanks for the help, Mike -- 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
