Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

"brian m. carlson" writes: > On Fri, Feb 05, 2016 at 12:18:22PM +0300, Dmitry Vilkov wrote: >> You are right, we are using a bare URL (without a username component). >> With username encoded in URL everything works just fine. But it's >> generally wrong to pass

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

On Fri, Feb 05, 2016 at 01:02:58PM -0800, Junio C Hamano wrote: > Hmph, so documenting that :@ > as a supported way might be an ugly-looking solution to the original > problem. A less ugly-looking solution might be a boolean that can > be set per URL (we already have urlmatch-config

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

On Fri, Feb 05, 2016 at 12:18:22PM +0300, Dmitry Vilkov wrote: > You are right, we are using a bare URL (without a username component). > With username encoded in URL everything works just fine. But it's > generally wrong to pass creds in URL (in my opinion) and security > policy of my employer

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

2016-02-03 2:29 GMT+03:00 brian m. carlson : > I'm unclear in what case you'd need to have a username and password > combination with GSS-Negotiate. Kerberos doesn't use your password, > although you need some indication of a username (valid or not) to get > libcurl

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

Dmitry Vilkov <dmitry.a.vil...@gmail.com> writes: > This is fix of bug introduced by 4dbe66464 commit. That would be 4dbe6646 (remote-curl: fall back to Basic auth if Negotiate fails, 2015-01-08) that appears in v2.3.1 and onward. > The problem is that when username/password

Re: [PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

On Tue, Feb 02, 2016 at 12:37:19PM -0800, Junio C Hamano wrote: > Dmitry Vilkov <dmitry.a.vil...@gmail.com> writes: > > > This is fix of bug introduced by 4dbe66464 commit. > > That would be 4dbe6646 (remote-curl: fall back to Basic auth if > Negotiate fails, 2015-01

[PATCH] remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

This is fix of bug introduced by 4dbe66464 commit. The problem is that when username/password combination was not set, the first HTTP(S) request will fail and user will be asked for credentials. As a side effect of first HTTP(S) request, libcurl auth method GSS-Negotiate will be disabled

[PATCH v4 1/1] Makefile: make curl-config path configurable

There are situations, e.g. during cross compilation, where curl-config program is not present in the PATH. Make the makefile use a configurable curl-config program passed through CURL_CONFIG variable which can be set through config.mak. Also make this variable tunable through use of autoconf

Re: [PATCH v4 1/1] Makefile: make curl-config path configurable

Remi Pommarel wrote: > Signed-off-by: Remi Pommarel > Reviewed-by: Jonathan Nieder Yep. ;) Thanks. -- 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

[PATCH v2 1/1] Makefile: make curl-config path configurable

There are situations, ie during cross compilation, where curl-config program is not present in the PATH. Make the makefile use a configurable curl-config program passed through CURL_CONFIG variable which can be set through config.mak. Also make this variable tunable through use of autoconf

[PATCH v3 1/1] Makefile: make curl-config path configurable

There are situations, e.g. during cross compilation, where curl-config program is not present in the PATH. Make the makefile use a configurable curl-config program passed through CURL_CONFIG variable which can be set through config.mak. Also make this variable tunable through use of autoconf

Re: [PATCH v3 1/1] Makefile: make curl-config path configurable

anks. > > [...] > > --- a/Makefile > > +++ b/Makefile > > @@ -39,6 +39,10 @@ all:: > > # Define CURLDIR=/foo/bar if your curl header and library files are in > > # /foo/bar/include and /foo/bar/lib directories. > > # > > +# Define CURL_CONFIG t

Re: [PATCH v3 1/1] Makefile: make curl-config path configurable

Remi Pommarel wrote: > Do I need to resend a v4 patch with these modifications ? I am not sure > about the correct workflow here. If you like the changes, you can ask Junio to squash them in. If you don't like them, that's also fine and you can just say so. -- To unsubscribe from this list:

Re: [PATCH v3 1/1] Makefile: make curl-config path configurable

On Mon, Oct 05, 2015 at 02:11:07PM -0700, Jonathan Nieder wrote: > Remi Pommarel wrote: > > > Do I need to resend a v4 patch with these modifications ? I am not sure > > about the correct workflow here. > > If you like the changes, you can ask Junio to squash them in. > > If you don't like

Re: [PATCH v2 1/1] Makefile: make curl-config path configurable

Remi Pommarel wrote: > There are situations, ie during cross compilation, where curl-config program > is not present in the PATH. s/ie/e.g.,/ [...] > @@ -374,6 +378,7 @@ LDFLAGS = > ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS) > ALL_LDFLAGS = $(LDFLAGS) > STRIP ?= strip > +CURL

Re: [PATCH v2 1/1] Makefile: make curl-config path configurable

On Mon, Oct 05, 2015 at 12:31:27PM -0700, Jonathan Nieder wrote: > Remi Pommarel wrote: > > > There are situations, ie during cross compilation, where curl-config program > > is not present in the PATH. > > s/ie/e.g.,/ Oups sorry about that. > > [...] &

Re: [PATCH v3 1/1] Makefile: make curl-config path configurable

Remi Pommarel wrote: > Signed-off-by: Remi Pommarel <r...@triplefau.lt> For what it's worth, with or without the tweaks below, Reviewed-by: Jonathan Nieder <jrnie...@gmail.com> [...] > --- a/Makefile > +++ b/Makefile > @@ -39,6 +39,10 @@ all:: > # Define CURLDIR=/

Re: [PATCH 1/1] configure: make curl-config path configurable

Remi Pommarel <r...@triplefau.lt> writes: > There are situations, ie during cross compilation, where curl-config program > is not present in the PATH. > > Make configure check that a custom curl-config program is passed by the user > through ac_cv_prog_CURL_CONFIG then set

[PATCH 1/1] configure: make curl-config path configurable

There are situations, ie during cross compilation, where curl-config program is not present in the PATH. Make configure check that a custom curl-config program is passed by the user through ac_cv_prog_CURL_CONFIG then set CURL_CONFIG variable accordingly in config.mak.autogen. Makefile uses

Re: curl

that it is the case. For the former, yes, libgit2 does not use curl. On Windows, it can use the native http calls (which do nice things like using the system proxy and auth systems). On Unix, I think it is a combination of hand-rolled code, openssl, and an imported http parser (from nginx

curl

Hi, Is it right that git uses libcurl to download while libgit2 does without it? -- Thiago Farina -- 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

Re: curl

curl. On Windows, it can use the native http calls (which do nice things like using the system proxy and auth systems). On Unix, I think it is a combination of hand-rolled code, openssl, and an imported http parser (from nginx). Whether that is a good idea or not, I can't comment too much. From

Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails

On Feb 25, 2015, at 3:59 PM, Dan Langille (dalangil) dalan...@cisco.com wrote: On Feb 24, 2015, at 4:03 PM, Dan Langille (dalangil) dalan...@cisco.com wrote: On Feb 19, 2015, at 3:35 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Wed, Feb 18, 2015 at 04:17:46PM +,

Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails

. I know that the web server should be able to figure it out from your credentials, so it shouldn't matter what username you provide. This is an unfortuate quirk of lib curl. I understand. Also, are you using 2.3.0, or one of the earlier patched versions? That might affect how it works. I am

Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails

On Mar 11, 2015, at 5:59 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Wed, Mar 11, 2015 at 07:33:05PM +, Dan Langille (dalangil) wrote: On Mar 10, 2015, at 6:29 PM, brian m. carlson sand...@crustytoothpaste.net wrote: Does it work with a ticket if you specify a

Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails

On Wed, Mar 11, 2015 at 07:33:05PM +, Dan Langille (dalangil) wrote: On Mar 10, 2015, at 6:29 PM, brian m. carlson sand...@crustytoothpaste.net wrote: Does it work with a ticket if you specify a username, as in the following URL? https://b...@git.crustytoothpaste.net/git/bmc/homedir.git

Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails

On Tue, Mar 10, 2015 at 06:05:46PM +, Dan Langille (dalangil) wrote: We have made progress I think. With stock git: tl;dr: 1 - with a ticket, you get prompted, but hitting ENTER succeeds. 2 - without a ticket, nothing works With patched git: tl;dr: 1 - with a ticket,entering

[PATCH] imap-send: use cURL automatically when NO_OPENSSL defined

If both USE_CURL_FOR_IMAP_SEND and NO_OPENSSL are defined do not force the user to add --curl to get a working git imap-send command. Instead automatically select --curl and warn and ignore the --no-curl option. And while we're in there, correct the warning message when --curl is requested

Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails

On Feb 24, 2015, at 4:03 PM, Dan Langille (dalangil) dalan...@cisco.com wrote: On Feb 19, 2015, at 3:35 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Wed, Feb 18, 2015 at 04:17:46PM +, Dan Langille (dalangil) wrote: I just built from ‘master’, on FreeBSD 9.3: cd

Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails

On Feb 19, 2015, at 3:35 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Wed, Feb 18, 2015 at 04:17:46PM +, Dan Langille (dalangil) wrote: I just built from ‘master’, on FreeBSD 9.3: cd ~/src git clone https://github.com/git/git.git cd git gmake Then tried

Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails

On Wed, Feb 18, 2015 at 04:17:46PM +, Dan Langille (dalangil) wrote: I just built from ‘master’, on FreeBSD 9.3: cd ~/src git clone https://github.com/git/git.git cd git gmake Then tried ~/src/git/git clone https://OUR_REPO It cores too, and I see: git-remote-https.core Can you

Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails

On Feb 17, 2015, at 6:36 PM, Junio C Hamano gits...@pobox.com wrote: Dan Langille (dalangil) dalan...@cisco.com writes: On Jan 20, 2015, at 7:22 PM, Junio C Hamano gits...@pobox.com wrote: Dan Langille (dalangil) dalan...@cisco.com writes: I did not test this patch. Is that holding up

Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails

On Jan 20, 2015, at 7:22 PM, Junio C Hamano gits...@pobox.com wrote: Dan Langille (dalangil) dalan...@cisco.com writes: I did not test this patch. Is that holding up a commit? I am hoping that you rebuilt the Git you use with this patch by the time you wrote the message I am responding

Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails

Dan Langille (dalangil) dalan...@cisco.com writes: On Jan 20, 2015, at 7:22 PM, Junio C Hamano gits...@pobox.com wrote: Dan Langille (dalangil) dalan...@cisco.com writes: I did not test this patch. Is that holding up a commit? I am hoping that you rebuilt the Git you use with this

[PATCH] http: support curl 7.10.7

Commit dd61399 introduced support for http proxies that require authentication but it relies on the CURL_PROXYAUTH option which was added in curl 7.10.7. This makes sure proxy authentication is only enabled if libcurl can support it. Signed-off-by: Tom G. Christensen t...@statsbiblioteket.dk

Re: [PATCH] Makefile: Handle broken curl version number in version check

) PROGRAM_OBJS += http-fetch.o PROGRAMS += $(REMOTE_CURL_NAMES) - curl_check := $(shell (echo 070908; curl-config --vernum) 2/dev/null | sort -r | sed -ne 2p) + curl_check := $(shell (echo 070908; curl-config --vernum | sed -e '/^70[B-C]/ s/^7/07/') 2/dev/null | sort -r | sed

Re: [PATCH] Makefile: Handle broken curl version number in version check

) $(REMOTE_CURL_ALIASES) PROGRAM_OBJS += http-fetch.o PROGRAMS += $(REMOTE_CURL_NAMES) - curl_check := $(shell (echo 070908; curl-config --vernum) 2/dev/ null | sort -r | sed -ne 2p) + curl_check := $(shell (echo 070908; curl-config --vernum | sed -e '/^70[B-C]/ s/^7/07/') 2/dev/null | sort -r | sed

Re: [PATCH] Makefile: Handle broken curl version number in version check

PROGRAMS += $(REMOTE_CURL_NAMES) - curl_check := $(shell (echo 070908; curl-config --vernum) 2/dev/null | sort -r | sed -ne 2p) + curl_check := $(shell (echo 070908; curl-config --vernum | sed -e '/^70[B-C]/ s/^7/07/') 2/dev/null | sort -r | sed -ne 2p) ifeq $(curl_check) 070908

Re: [PATCH] Makefile: Handle broken curl version number in version check

PROGRAMS += $(REMOTE_CURL_NAMES) - curl_check := $(shell (echo 070908; curl-config --vernum) 2/dev/null | sort -r | sed -ne 2p) + curl_check := $(shell (echo 070908; curl-config --vernum | sed -e '/^70[B-C]/ s/^7/07/') 2/dev/null | sort -r | sed -ne 2p) How about 's/^.$/0

[PATCH] Makefile: Handle broken curl version number in version check

curl 7.11.0 through 7.12.2 when built from their official release archives will present a 5 digit version number instead of the documented 6 digits which breaks the version check in the Makefile. Correct these broken version numbers on the fly when extracting them to ensure the comparison works

Broken makefile check for curl version on el4 [Re: [ANNOUNCE] Git v2.3.0-rc2]

On 28/01/15 00:35, Junio C Hamano wrote: A release candidate Git v2.3.0-rc2 is now available for testing at the usual places. Building is broken on RHEL4 which is a regression from 2.2.2. The makefile check for curl = 7.34.0 fails and enables USE_CURL_FOR_IMAP_SEND even though curl

Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails

On Jan 20, 2015, at 7:22 PM, Junio C Hamano gits...@pobox.com wrote: Dan Langille (dalangil) dalan...@cisco.com writes: I did not test this patch. Is that holding up a commit? I am hoping that you rebuilt the Git you use with this patch by the time you wrote the message I am responding

Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails

http_auth_methods = CURLAUTH_ANY; +#endif static struct curl_slist *pragma_header; static struct curl_slist *no_pragma_header; @@ -580,6 +583,9 @@ struct active_request_slot *get_active_slot(void) curl_easy_setopt(slot-curl, CURLOPT_UPLOAD, 0); curl_easy_setopt(slot-curl, CURLOPT_HTTPGET, 1

Re: [PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails

Dan Langille (dalangil) dalan...@cisco.com writes: I did not test this patch. Is that holding up a commit? I am hoping that you rebuilt the Git you use with this patch by the time you wrote the message I am responding to and have been using it for your daily Git needs ;-) I believe it is

Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails

On Tue, Jan 06, 2015 at 04:07:01PM +, Dan Langille (dalangil) wrote: HTTP/1.1 401 Authorization Required Date: Tue, 06 Jan 2015 16:02:48 GMT Server: Apache WWW-Authenticate: Negotiate Your server is set up incorrectly. You should see a Negotiate line and a Basic line as well. Right

[PATCH v3] remote-curl: fall back to Basic auth if Negotiate fails

LIBCURL_CAN_HANDLE_AUTH_ANY +static unsigned long http_auth_methods = CURLAUTH_ANY; +#endif static struct curl_slist *pragma_header; static struct curl_slist *no_pragma_header; @@ -580,6 +583,9 @@ struct active_request_slot *get_active_slot(void) curl_easy_setopt(slot-curl, CURLOPT_UPLOAD, 0

Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails

On Jan 5, 2015, at 6:53 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Mon, Jan 05, 2015 at 09:23:32PM +, Dan Langille (dalangil) wrote: I have tried both patches. Neither succeeds here. I patched git version 2.2.1 but I don’t think that affects this. You are patching

Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails

On Jan 6, 2015, at 10:31 AM, Dan Langille (dalangil) dalan...@cisco.com wrote: On Jan 5, 2015, at 6:53 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Mon, Jan 05, 2015 at 09:23:32PM +, Dan Langille (dalangil) wrote: I have tried both patches. Neither succeeds here. I

Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails

On Jan 6, 2015, at 10:31 AM, Dan Langille (dalangil) dalan...@cisco.com wrote: On Jan 5, 2015, at 6:53 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Mon, Jan 05, 2015 at 09:23:32PM +, Dan Langille (dalangil) wrote: I have tried both patches. Neither succeeds here. I

Re: [PATCH] remote-curl: fall back to Basic auth if Negotiate fails.

active_request_slot *slot) +{ +#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY +#define HTTP_AUTH_PASSWORDLESS (CURLAUTH_GSSNEGOTIATE) + curl_easy_setopt(slot-curl, CURLOPT_HTTPAUTH, + CURLAUTH_ANY ~HTTP_AUTH_PASSWORDLESS); +#endif +} + + /* http_request() targets */ #define

Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails

On Mon, Jan 05, 2015 at 09:23:32PM +, Dan Langille (dalangil) wrote: I have tried both patches. Neither succeeds here. I patched git version 2.2.1 but I don’t think that affects this. You are patching the client side, correct? That's the side that needs patching here. Just so the

Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails

disable_passwordless_auth(struct active_request_slot *slot) +{ +#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY +#define HTTP_AUTH_PASSWORDLESS (CURLAUTH_GSSNEGOTIATE) + curl_easy_setopt(slot-curl, CURLOPT_HTTPAUTH, + CURLAUTH_ANY ~HTTP_AUTH_PASSWORDLESS); +#endif +} + + /* http_request

Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails

); } +void disable_passwordless_auth(struct active_request_slot *slot) +{ +#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY +#define HTTP_AUTH_PASSWORDLESS (CURLAUTH_GSSNEGOTIATE) + curl_easy_setopt(slot-curl, CURLOPT_HTTPAUTH, + CURLAUTH_ANY ~HTTP_AUTH_PASSWORDLESS); +#endif

Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails

On Thu, Jan 01, 2015 at 07:56:27PM +, brian m. carlson wrote: +void disable_passwordless_auth(struct active_request_slot *slot) +{ +#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY +#define HTTP_AUTH_PASSWORDLESS (CURLAUTH_GSSNEGOTIATE) + curl_easy_setopt(slot-curl, CURLOPT_HTTPAUTH

Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails

-based authentication (e.g. GSSAPI)? */ +static int http_passwordless_auth = 1; static struct curl_slist *pragma_header; static struct curl_slist *no_pragma_header; @@ -318,7 +320,12 @@ static CURL *get_curl_handle(void) curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL); #endif

Re: [PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails

-off since it will essentially be your work. I think curl typically uses signed long for flags, but certainly check the docs to be sure. I was thinking it would be integer-promoted in this case, but I'm not sure that works always (certainly it does not if CURLAUTH_ANY needs high bits, but depending

[PATCH v2] remote-curl: fall back to Basic auth if Negotiate fails

, strbuf_addstr(charset, ISO-8859-1); } +void disable_passwordless_auth(struct active_request_slot *slot) +{ +#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY +#define HTTP_AUTH_PASSWORDLESS (CURLAUTH_GSSNEGOTIATE) + curl_easy_setopt(slot-curl, CURLOPT_HTTPAUTH, +CURLAUTH_ANY

Re: [PATCH] remote-curl: fall back to Basic auth if Negotiate fails.

On Sat, Dec 27, 2014 at 04:01:33AM +, brian m. carlson wrote: Apache servers using mod_auth_kerb can be configured to allow the user to authenticate either using Negotiate (using the Kerberos ticket) or Basic authentication (using the Kerberos password). Often, one will want to use

Re: [PATCH] remote-curl: fall back to Basic auth if Negotiate fails.

On Sat, Dec 27, 2014 at 12:56:04PM -0500, Jeff King wrote: On Sat, Dec 27, 2014 at 04:01:33AM +, brian m. carlson wrote: Apache servers using mod_auth_kerb can be configured to allow the user to authenticate either using Negotiate (using the Kerberos ticket) or Basic authentication

Re: [PATCH] remote-curl: fall back to Basic auth if Negotiate fails.

On Sat, Dec 27, 2014 at 09:09:36PM +, brian m. carlson wrote: I'm not familiar enough with Negotiate auth to do give a thorough review on the logic above. But FWIW, it makes sense to me, and the code looks correct. libcurl will try very hard to use something other than Basic auth,

Re: [PATCH] remote-curl: fall back to Basic auth if Negotiate fails.

On Sat, Dec 27, 2014 at 04:29:49PM -0500, Jeff King wrote: since if they failed the first time, they will never succeed Are there other GSSAPI methods where this is not the case? I don't know of any, and AFAICT git's support is used only for Kerberos, so this is probably safe for now. If

[PATCH] remote-curl: fall back to Basic auth if Negotiate fails.

LIBCURL_CAN_HANDLE_AUTH_ANY +#define HTTP_AUTH_PASSWORDLESS (CURLAUTH_GSSNEGOTIATE) + curl_easy_setopt(slot-curl, CURLOPT_HTTPAUTH, +CURLAUTH_ANY ~HTTP_AUTH_PASSWORDLESS); +#endif +} + + /* http_request() targets */ #define HTTP_REQUEST_STRBUF0 #define HTTP_REQUEST_FILE 1

[PATCH] imap-send: avoid curl functions when not building curl support

Imap-send recently learned to conditionally compile against and use curl for imap support. To use this feature, you must both: 1. Compile with USE_CURL_FOR_IMAP_SEND 2. Specify --curl on the command line to enable it It is OK (and even desirable) for the code checking --curl to be compiled

Re: [PATCH] imap-send: avoid curl functions when not building curl support

On Mon, Nov 10, 2014 at 01:39:47AM -0500, Jeff King wrote: On top of br/imap-send-via-libcurl. I needed this to compile 'pu' with NO_CURL (which I don't usually do, but was testing on a minimal box). I expect it can just be squashed in to the next re-roll. Oops, just started reading through

[PATCH 05/14] MINGW: config.mak.uname: allow using cURL for non-msysGit builds

Is it absolutely valid and possible to have cURL in generic MinGW environment. Building Git without cURL is still possible by passing NO_CURL=1 Signed-off-by: Marat Radchenko ma...@slonopotamus.org Acked-by: Eric Faye-Lund kusmab...@gmail.com --- config.mak.uname | 2 -- 1 file changed, 2

[PATCH 05/14] MINGW: config.mak.uname: allow using cURL for non-msysGit builds

Is it absolutely valid and possible to have cURL in generic MinGW environment. Building Git without cURL is still possible by passing NO_CURL=1 Signed-off-by: Marat Radchenko ma...@slonopotamus.org Acked-by: Eric Faye-Lund kusmab...@gmail.com --- config.mak.uname | 2 -- 1 file changed, 2

[PATCH 05/14] MINGW: config.mak.uname: allow using cURL for non-msysGit builds

Is it absolutely valid and possible to have cURL in generic MinGW environment. Building Git without cURL is still possible by passing NO_CURL=1 Signed-off-by: Marat Radchenko ma...@slonopotamus.org Acked-by: Eric Faye-Lund kusmab...@gmail.com --- config.mak.uname | 2 -- 1 file changed, 2

[PATCH] remote-curl: do not complain on EOF from parent git

The parent git process is supposed to send us an empty line to indicate that the conversation is over. However, the parent process may die() if there is a problem with the operaiton (e.g., we try to fetch a ref that does not exist). In this case, it produces a useful message, but then remote-curl

Re: [PATCH] remote-curl: do not complain on EOF from parent git

, but you probably meant operation here. Thanks, Jake In this case, it produces a useful message, but then remote-curl _also_ produces an unhelpful message: $ git pull origin matser fatal: couldn't find remote ref matser Unexpected end of command stream The right way to fix

Re: [PATCH] remote-curl: do not complain on EOF from parent git

On Wed, Jul 09, 2014 at 09:25:18PM +, Keller, Jacob E wrote: On Wed, 2014-07-09 at 17:20 -0400, Jeff King wrote: The parent git process is supposed to send us an empty line to indicate that the conversation is over. However, the parent process may die() if there is a problem with the

[PATCH 1/3] remote-curl: do not complain on EOF from parent git

The parent git process is supposed to send us an empty line to indicate that the conversation is over. However, the parent process may die() if there is a problem with the operation (e.g., we try to fetch a ref that does not exist). In this case, it produces a useful message, but then remote-curl

[PATCH 3/3] remote-curl: mark helper-protocol errors more clearly

When we encounter an error in remote-curl, we generally just report it to stderr. There is no need for the user to care that the could not connect to server error was generated by git-remote-https rather than a function in the parent git-fetch process. However, when the error is in the protocol

[PATCH 2/3] remote-curl: use error instead of fprintf(stderr)

We usually prefix our error messages with error: , but many error messages from remote-curl are simply printed with fprintf. This can make the output a little harder to read (especially because such message may be intermingled with errors from the parent git process). There is no reason to avoid

[PATCH v2 15/19] remote-curl: simplify via strbuf_set()

Simplify cases where a strbuf_reset is immediately followed by a strbuf_add by using strbuf_set operations. Signed-off-by: Jeremiah Mahler jmmah...@gmail.com --- remote-curl.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/remote-curl.c b/remote-curl.c index

Re: [PATCH 7/9] remote-curl: recognize text/plain with a charset parameter

On Wed, May 21, 2014 at 05:07:38PM -0700, Kyle J. McKay wrote: +p = skip_prefix(type-buf, text/plain); +if (!p || (*p *p != ';')) +return 0; + +return 1; +} + I think that a strict reading of RFC 2616 allows text/plain ; charset=utf-8 as well as

Re: [PATCH 9/9] remote-curl: reencode http error messages

On Wed, May 21, 2014 at 05:07:40PM -0700, Kyle J. McKay wrote: +/* default charset from rfc2616 */ +if (!*charset) +*charset = xstrdup(iso8859-1); Actually the name should be ISO-8859-1. See RFC 2616 section 3.7.1. Since it's case insensitive iso-8859-1 would be fine

Re: [PATCH 7/9] remote-curl: recognize text/plain with a charset parameter

Kyle J. McKay: I think that a strict reading of RFC 2616 allows text/plain ; charset=utf-8 as well as text/plain;charset=utf-8 and text/plain; charset=utf-8. It does indeed, and I have seen servers send both variants, so they do need to be catered for. The number of servers that would

Re: [PATCH 9/9] remote-curl: reencode http error messages

Kyle J. McKay: + if (!*charset) + *charset = xstrdup(iso8859-1); Actually the name should be ISO-8859-1. See RFC 2616 section 3.7.1. Since it's case insensitive iso-8859-1 would be fine too. You'd be amazed at what you see in the wild... I'd recommend going with the

Re: [PATCH 7/9] remote-curl: recognize text/plain with a charset parameter

On May 21, 2014, at 23:05, Jeff King wrote: On Wed, May 21, 2014 at 05:07:38PM -0700, Kyle J. McKay wrote: + p = skip_prefix(type-buf, text/plain); + if (!p || (*p *p != ';')) + return 0; + + return 1; +} + I think that a strict reading of RFC 2616 allows

Re: [PATCH 7/9] remote-curl: recognize text/plain with a charset parameter

On Thu, May 22, 2014 at 12:27:38AM -0700, Kyle J. McKay wrote: Yeah I think so too. It's probably enough though just to just strip all and \t characters at the same time the content type is lowercased. While that would cause invalid content types such as text / plain to be recognized it

Re: [PATCH 7/9] remote-curl: recognize text/plain with a charset parameter

On Thu, May 22, 2014 at 08:12:58AM +0100, Peter Krefting wrote: Kyle J. McKay: I think that a strict reading of RFC 2616 allows text/plain ; charset=utf-8 as well as text/plain;charset=utf-8 and text/plain; charset=utf-8. It does indeed, and I have seen servers send both variants, so

[PATCH v2 7/8] remote-curl: reencode http error messages

We currently recognize an error message with a content-type text/plain; charset=utf-16 as text, but we ignore the charset parameter entirely. Let's encode it to log_output_encoding, which is presumably something the user's terminal can handle. Signed-off-by: Jeff King p...@peff.net ---

Re: [PATCH 7/9] remote-curl: recognize text/plain with a charset parameter

Jeff King: I was really hoping to avoid getting into all of the real-world messiness that a real http client needs to deal with (as opposed to just following the standards). Yeah, I agree, you're probably fine without all this detail in over 99% of the cases where this code would ever be

[PATCH 7/9] remote-curl: recognize text/plain with a charset parameter

Commit 426e70d (remote-curl: show server content on http errors, 2013-04-05) tried to recognize text/plain content types, but fails to do so if they have any parameters. This patches makes our parsing more liberal, though we still do not do anything useful with a charset parameter. Signed-off

[PATCH 9/9] remote-curl: reencode http error messages

As of the last commit, we now recognize an error message with a content-type text/plain; charset=utf-16 as text, but we ignore the charset parameter entirely. Let's encode it to log_output_encoding, which is presumably something the user's terminal can handle. Signed-off-by: Jeff King

Re: [PATCH 7/9] remote-curl: recognize text/plain with a charset parameter

On May 21, 2014, at 03:33, Jeff King wrote: Commit 426e70d (remote-curl: show server content on http errors, 2013-04-05) tried to recognize text/plain content types, but fails to do so if they have any parameters. This patches makes our parsing more liberal, though we still do not do anything

Re: [PATCH 9/9] remote-curl: reencode http error messages

On May 21, 2014, at 03:33, Jeff King wrote: As of the last commit, we now recognize an error message with a content-type text/plain; charset=utf-16 as text, but we ignore the charset parameter entirely. Let's encode it to log_output_encoding, which is presumably something the user's terminal

Re: [PATCH/RFC] Makefile: do not depend on curl-config

On Wed, Apr 30, 2014 at 9:46 PM, Sebastian Schuberth sschube...@gmail.com wrote: On Wed, Apr 30, 2014 at 6:52 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: We can keep this patch in the msysGit repo for the 2.0 release. FWIW the plan is to switch to mingwGitDevEnv for the 2.0

Re: [PATCH/RFC] Makefile: do not depend on curl-config

On Mon, May 5, 2014 at 12:53 PM, Erik Faye-Lund kusmab...@gmail.com wrote: FWIW the plan is to switch to mingwGitDevEnv for the 2.0 release. It is not quite clear as of yet how patches will be managed with said environment. The environment is just that: The environment to build Git for

Re: [msysGit] Re: [PATCH/RFC] Makefile: do not depend on curl-config

Am 05.05.2014 12:53, schrieb Erik Faye-Lund: On Wed, Apr 30, 2014 at 9:46 PM, Sebastian Schuberth sschube...@gmail.com wrote: On Wed, Apr 30, 2014 at 6:52 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: We can keep this patch in the msysGit repo for the 2.0 release. FWIW the plan

Re: [PATCH/RFC] Makefile: do not depend on curl-config

On Mon, Apr 28, 2014 at 6:29 PM, Erik Faye-Lund kusmab...@gmail.com wrote: MinGW builds of cURL does not ship with curl-config unless built with the autoconf based build system, which is not the practice recommended by the documentation. MsysGit has had issues with binaries of that sort, so

Re: [PATCH/RFC] Makefile: do not depend on curl-config

Erik Faye-Lund kusmab...@gmail.com writes: MinGW builds of cURL does not ship with curl-config unless built with the autoconf based build system, which is not the practice recommended by the documentation. MsysGit has had issues with binaries of that sort, so it has switched away from

Re: [PATCH/RFC] Makefile: do not depend on curl-config

On Wed, Apr 30, 2014 at 8:27 AM, Junio C Hamano gits...@pobox.com wrote: How old/battle tested is this change? My inclination at this point is to revert the merge of Dave's series from 2.0 (yes, I know we have been looking at fixing it and I _think_ the issue of unpleasant error message you

Re: [PATCH/RFC] Makefile: do not depend on curl-config

On Wed, Apr 30, 2014 at 5:27 PM, Junio C Hamano gits...@pobox.com wrote: Erik Faye-Lund kusmab...@gmail.com writes: MinGW builds of cURL does not ship with curl-config unless built with the autoconf based build system, which is not the practice recommended by the documentation. MsysGit has

Re: [PATCH/RFC] Makefile: do not depend on curl-config

Hi kusma, On Wed, 30 Apr 2014, Erik Faye-Lund wrote: We can keep this patch in the msysGit repo for the 2.0 release. FWIW the plan is to switch to mingwGitDevEnv for the 2.0 release. It is not quite clear as of yet how patches will be managed with said environment. Ciao, Johannes -- To

Re: [PATCH/RFC] Makefile: do not depend on curl-config

On Wed, Apr 30, 2014 at 6:52 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: We can keep this patch in the msysGit repo for the 2.0 release. FWIW the plan is to switch to mingwGitDevEnv for the 2.0 release. It is not quite clear as of yet how patches will be managed with said

[PATCH 05/12] MINGW: config.mak.uname: allow using cURL for non-msysGit builds

Is it absolutely valid and possible to have cURL in generic MinGW environment. Building Git without cURL is still possible by passing NO_CURL=1 Signed-off-by: Marat Radchenko ma...@slonopotamus.org Acked-by: Eric Faye-Lund kusmab...@gmail.com --- config.mak.uname | 2 -- 1 file changed, 2

[PATCH 08/12] MINGW: config.mak.uname allow using CURL for non-msysGit builds

Also, fix `warning: passing argument 2 of 'mingw_main' from incompatible pointer type` in http-fetch.c and remote-curl.c. Signed-off-by: Marat Radchenko ma...@slonopotamus.org --- config.mak.uname | 2 -- http-fetch.c | 5 +++-- remote-curl.c| 2 +- 3 files changed, 4 insertions(+), 5

Re: [PATCH 08/12] MINGW: config.mak.uname allow using CURL for non-msysGit builds

On Mon, Apr 28, 2014 at 3:51 PM, Marat Radchenko ma...@slonopotamus.org wrote: Also, fix `warning: passing argument 2 of 'mingw_main' from incompatible pointer type` in http-fetch.c and remote-curl.c. These seems completely unrelated, perhaps it should be split in two? -- To unsubscribe from

Re: [PATCH 08/12] MINGW: config.mak.uname allow using CURL for non-msysGit builds

On Mon, Apr 28, 2014 at 05:26:38PM +0200, Erik Faye-Lund wrote: On Mon, Apr 28, 2014 at 3:51 PM, Marat Radchenko ma...@slonopotamus.org wrote: Also, fix `warning: passing argument 2 of 'mingw_main' from incompatible pointer type` in http-fetch.c and remote-curl.c. These seems completely

<    1   2   3   4   5   >