On Mon, Apr 28, 2014 at 6:23 PM, Marat Radchenko ma...@slonopotamus.org wrote:
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
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 autoconf-based
cURL-builds.
Unfortunately, broke
Hi,
Dave Borowitz wrote:
curl-config is usually installed alongside a curl distribution, and
its purpose is to provide flags for building against libcurl, so use
it instead of guessing flags and dependent libraries.
The previous version of these two patches is already part of master.
Could
.
ifdef CURLDIR
+ CURL_LIBCURL=
else
+ CURL_CONFIG ?= curl-config
+ ifeq $(CURL_CONFIG)
+ CURL_LIBCURL =
+ else
+ CURL_LIBCURL := $(shell $(CURL_CONFIG) --libs)
endif
This ifeq
On Mon, Apr 28, 2014 at 12:44 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi,
Dave Borowitz wrote:
curl-config is usually installed alongside a curl distribution, and
its purpose is to provide flags for building against libcurl, so use
it instead of guessing flags and dependent libraries
to CURL_LIBCURL case, so the result is good.
I haven't checked what it would look like if we turn this into an
incremental patch to be applied on top of 'master' (which would give
us a place to document better why we do not rely on the presense of
curl-config), but if we can do so, that would be more
Junio C Hamano gits...@pobox.com writes:
This ifeq is redundant and will never set CURL_LIBCURL to empty
without running the else part, I think. In a Makefile, a variable
explicitly set to empty and a variable that is unset are treated the
same
$ make -f Makefile CURL_CONFIG=
On Mon, Apr 14, 2014 at 4:22 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
curl-config should always be installed alongside a curl distribution,
and its purpose is to provide flags for building against libcurl, so
use it instead of guessing flags
curl-config should always be installed alongside a curl distribution,
and its purpose is to provide flags for building against libcurl, so
use it instead of guessing flags and dependent libraries.
Allow overriding CURL_CONFIG to a custom path to curl-config, to
compile against a curl installation
Dave Borowitz dborow...@google.com writes:
My end goal is to statically link git on Mac OS X (10.9) against a
newer version of libcurl than ships with the OS. The normal CURLDIR
approach should work with system libcurl:
$ /usr/bin/curl-config --libs
-lcurl
But it gets a bit more
Dave Borowitz dborow...@google.com writes:
curl-config should always be installed alongside a curl distribution,
and its purpose is to provide flags for building against libcurl, so
use it instead of guessing flags and dependent libraries.
Allow overriding CURL_CONFIG to a custom path
curl-config should always be installed alongside a curl distribution,
and its purpose is to provide flags for building against libcurl, so
use it instead of guessing flags and dependent libraries.
Allow overriding CURL_CONFIG to a custom path to curl-config, to
compile against a curl installation
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
compat/vcbuild/scripts/clink.pl | 2 ++
config.mak.uname| 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/compat/vcbuild/scripts/clink.pl b/compat/vcbuild/scripts/clink.pl
index 4374771..a87d0da 100755
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/fetch-pack.c | 7 +++
remote-curl.c| 3 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index 927424b..aa6e596 100644
--- a/builtin/fetch-pack.c
+++
On Mon, 25 Nov 2013, Jeff King wrote:
This is an extension to the fix in 7d80ed64e43515. We may call
Curl_disconnect() while cleaning up the multi handle, which could lead to
openssl sending packets, which could get a SIGPIPE.
Thanks a lot. I'll merge these ones in a second and they will be
don't know if that has any portability implications.
I almost wonder if the SIGPIPE_IGNORE definition (and inclusion of
signal.h) should go into curl-setup.h. I have very little knowledge of
the curl code base and conventions, so please feel free to hack it up or
point me in the right direction
..2ecb1a4 100644
--- a/lib/multi.c
+++ b/lib/multi.c
@@ -41,6 +41,7 @@
#include bundles.h
#include multihandle.h
#include pipeline.h
+#include sigpipe.h
#define _MPRINTF_REPLACE /* use our functions only */
#include curl/mprintf.h
@@ -1786,12 +1787,18 @@ CURLMcode curl_multi_cleanup(CURLM
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/fetch-pack.c | 7 +++
remote-curl.c| 3 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index 927424b..aa6e596 100644
--- a/builtin/fetch-pack.c
+++
read over the result to make
sure I am not defaming you. :)
I noticed while committing the first patch that we do not actually
follow the do not look at curl after finish_active_slot rule for the
content-type. Again, we get away with it because we are not running
multiple slots at the time (we only
slot_results results_buf;
- slot-results = results;
+ if (!results)
+ results = results_buf;
+
+ slot-results = results;
slot-curl_result = curl_easy_perform(slot-curl);
finish_active_slot(slot);
- err = handle_curl_result(results);
+ err
From: brian m. carlson sand...@crustytoothpaste.net
Due to an interaction between the way libcurl handles GSSAPI
authentication over HTTP and the way git uses libcurl, large
pushes (those over http.postBuffer bytes) would fail due to
an authentication failure requiring a rewind of the curl
buffer
to
an authentication failure requiring a rewind of the curl
buffer. Such a rewind was not possible because the data did
not fit into the entire buffer.
Enable the use of the Expect: 100-continue header for large
requests where the server offers GSSAPI authentication to
avoid this issue, since
.
+#if LIBCURL_VERSION_NUM = 0x070a08
+ slot = get_active_slot();
+ curl_easy_getinfo(slot-curl, CURLINFO_HTTPAUTH_AVAIL,
authtype);
+ if (authtype CURLAUTH_GSSNEGOTIATE)
+ needs_100_continue = 1;
+#endif
I didn't notice this in the last round
On Wed, Oct 30, 2013 at 04:45:10AM -0400, Jeff King wrote:
However, we do reuse the curl handles. And in the case of rpc case, we
are only doing one request at a time, so the handle you get is
guaranteed to be the last one used. So it works in practice, but it
would break if the curl handle
minor nit:
+ slot = get_active_slot();
+ curl_easy_getinfo(slot-curl, CURLINFO_HTTPAUTH_AVAIL,
authtype);
+ if (authtype CURLAUTH_GSSNEGOTIATE)
+ needs_100_continue = 1;
According to curl_easy_getinfo(3), CURLINFO_HTTPAUTH_AVAIL
Due to an interaction between the way libcurl handles GSSAPI authentication over
HTTP and the way git uses libcurl, large pushes (those over http.postBuffer
bytes) would fail due to an authentication failure requiring a rewind of the
curl buffer. Such a rewind was not possible because the data
Due to an interaction between the way libcurl handles GSSAPI authentication over
HTTP and the way git uses libcurl, large pushes (those over http.postBuffer
bytes) would fail due to an authentication failure requiring a rewind of the
curl buffer. Such a rewind was not possible because the data
In the discover_refs function, we use a strbuf named
buffer for multiple purposes. First we build the info/refs
URL in it, and then detach that to a bare pointer. Then, we
use the same strbuf to store the result of fetching the
refs.
Let's instead keep a separate refs_url strbuf. This is less
For efficiency and security reasons, an earlier commit in
this series taught http_get_* to re-write the base url based
on redirections we saw while making a specific request.
This commit wires that option into the info/refs request,
meaning that a redirect from
We use a strbuf to generate the string containing the remote
URL, but then detach it to a bare pointer. This makes it
harder to later manipulate the URL, as we have forgotten the
length (and the allocation semantics are not as clear).
Let's instead keep the strbuf around. As a bonus, this
The URL included in the header appears to vary from curl version to
curl version. Since we only care about the final few lines, only test
them. However, make sure the blank line after the header is still
included to make sure there are no extra cookie lines.
Signed-off-by: Brian Gernhardt br
-curl to record and display the
body content of a failed http response. We only display such
responses when the content-type is advertised as text/plain,
as it is the most likely to look presentable on the user's
terminal (and it is hoped to be a good indication that the
message is intended for git
are not in control of the server
repo, the advice is useless and confusing.
The previous patch taught remote-curl to show custom advice
from the server when it is available. When we have shown
messages from the server, we can also drop our custom
advice; what the server has to say is likely to be more
When we get an http 404 trying to get the initial list of
refs from the server, we try to be helpful and remind the
user that update-server-info may need to be run. This looks
like:
$ git clone https://github.com/non/existent
Cloning into 'existent'...
fatal:
When we report http errors in fetching the initial ref
advertisement, we show the full URL we attempted to use,
including info/refs?service=git-upload-pack. While this
may be useful for debugging a broken server, it is
unnecessarily verbose and confusing for most cases, in which
the client user is
When we encounter an unknown http error (e.g., a 403), we
hand the error code to http_error, which then prints it with
error(). After that we die with the redundant message HTTP
request failed.
Instead, let's just drop http_error entirely, which does
nothing but pass arguments to error(), and
Until recently, get_remote_heads only knew how to read refs
from a file descriptor. To hack around this, we spawned a
thread (or forked a process) to write the buffer back to us.
Now that we can just pass it our buffer directly, we don't
have to use this hack anymore.
Signed-off-by: Jeff King
The ref-parsing functions are static. Let's move them up in
the file to be available to more functions, which will help
us with later refactoring.
Signed-off-by: Jeff King p...@peff.net
---
remote-curl.c | 118 +-
1 file changed, 59
When remote-curl receives a list of refs from a server, it
keeps the whole buffer intact. When we get a list command,
we feed the result to get_remote_heads, and when we get a
fetch or push command, we feed it to fetch-pack or
send-pack, respectively.
If the HTTP response from the server
On Mon, Feb 18, 2013 at 1:12 AM, Jeff King p...@peff.net wrote:
On Sun, Feb 17, 2013 at 05:41:13PM -0800, Jonathan Nieder wrote:
I don't think so. Don't ERR lines appear inside their own packets?
Yes, I misread get_remote_heads for some reason. Thanks for checking.
Thanks for bringing it
On Mon, Feb 18, 2013 at 1:49 AM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
On Mon, Feb 18, 2013 at 01:29:16AM -0800, Junio C Hamano wrote:
I just checked, and GitHub also does not send flush packets after ERR.
Which makes sense; ERR is supposed to end the
On Mon, Feb 18, 2013 at 1:30 AM, Jeff King p...@peff.net wrote:
When remote-curl receives a list of refs from a server, it
keeps the whole buffer intact. When we get a list command,
we feed the result to get_remote_heads, and when we get a
fetch or push command, we feed it to fetch-pack
On Sun, Feb 17, 2013 at 04:54:43PM -0800, Jonathan Nieder wrote:
My intent was that it followed the error convention of negative is
error, 0 is success, and positive is not used, but reserved for
future use.
From a maintainability perspective, that kind of contract would be
dangerous,
buffer
[08/10]: remote-curl: pass buffer straight to get_remote_heads
These all build on each other to get rid of the extra thread/pipe, which
I think is worth doing even without the rest of the series.
[09/10]: remote-curl: move ref-parsing code up in file
[10/10]: remote-curl: always parse
Until recently, get_remote_heads only knew how to read refs
from a file descriptor. To hack around this, we spawned a
thread (or forked a process) to write the buffer back to us.
Now that we can just pass it our buffer directly, we don't
have to use this hack anymore.
Signed-off-by: Jeff King
Jeff King p...@peff.net writes:
On Sun, Feb 17, 2013 at 05:41:13PM -0800, Jonathan Nieder wrote:
I don't think so. Don't ERR lines appear inside their own packets?
Yes, I misread get_remote_heads for some reason. Thanks for checking.
Thanks for bringing it up. I had not even thought
The ref-parsing functions are static. Let's move them up in
the file to be available to more functions, which will help
us with later refactoring.
Signed-off-by: Jeff King p...@peff.net
---
Just a cleanup for the next patch. We could also just do extra
declarations at the top.
remote-curl.c |
When remote-curl receives a list of refs from a server, it
keeps the whole buffer intact. When we get a list command,
we feed the result to get_remote_heads, and when we get a
fetch or push command, we feed it to fetch-pack or
send-pack, respectively.
If the HTTP response from the server
On Mon, Feb 18, 2013 at 01:29:16AM -0800, Junio C Hamano wrote:
I just checked, and GitHub also does not send flush packets after ERR.
Which makes sense; ERR is supposed to end the conversation.
Hmph. A flush packet was supposed to be a mark to say all the
packets before this one can be
Jeff King p...@peff.net writes:
On Mon, Feb 18, 2013 at 01:29:16AM -0800, Junio C Hamano wrote:
I just checked, and GitHub also does not send flush packets after ERR.
Which makes sense; ERR is supposed to end the conversation.
Hmph. A flush packet was supposed to be a mark to say all
On Mon, Feb 18, 2013 at 01:49:37AM -0800, Junio C Hamano wrote:
The logic behind the comment we do not buffer, but we should is
that flush tells the receiver that the sending end is done feeding
it a class of data, and the data before flush do not have to reach
the receiver immediately, hence
Jeff King wrote:
I don't know that this code was hurting anything, but it has always
struck me as ugly and a possible source of error. And now it's gone.
Heh. Belongs in the commit message, presumably.
I don't think the async procedure was very harmful, but it's nice to
avoid the cost of a
Jeff King wrote:
remote-curl.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
I like.
--
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
Jeff King wrote:
--- a/remote-curl.c
+++ b/remote-curl.c
[...]
@@ -155,11 +166,13 @@ static struct discovery* discover_refs(const char
*service)
[...]
- strbuf_reset(buffer);
- while (packet_get_line(buffer, last-buf, last-len) 0)
-
in the normal fetching
workflow, because git-fetch first uses the list command,
which feeds the refs to get_remote_heads, which does notice
the error. However, you can trigger it by sending a direct
fetch to the remote-curl helper.
Ah. Would a test for this make sense?
[...]
--- a/remote-curl.c
+++ b
On Sun, Feb 17, 2013 at 02:49:39AM -0800, Jonathan Nieder wrote:
Jeff King wrote:
--- a/remote-curl.c
+++ b/remote-curl.c
[...]
@@ -155,11 +166,13 @@ static struct discovery* discover_refs(const char
*service)
[...]
- strbuf_reset(buffer);
- while
to figure out
what was going on.
[...]
This fortunately doesn't happen in the normal fetching
workflow, because git-fetch first uses the list command,
which feeds the refs to get_remote_heads, which does notice
the error. However, you can trigger it by sending a direct
fetch to the remote-curl
Jeff King wrote:
On Sun, Feb 17, 2013 at 02:49:39AM -0800, Jonathan Nieder wrote:
Jeff King wrote:
--- a/remote-curl.c
[...]
+ if (read_packets_until_flush(last-buf, last-len) 0)
Style nit: this made me wonder What would it mean if
read_packets_until_flush() 0?
[...]
My
Jeff King wrote:
On Sun, Feb 17, 2013 at 03:05:34AM -0800, Jonathan Nieder wrote:
Jeff King wrote:
+ if (verify_ref_advertisement(last-buf, last-len) 0)
+ die(ref advertisement is invalid at %s, refs_url);
Won't this error out with
protocol error: bad
A smart http ref advertisement starts with a packet
containing the service header, followed by an arbitrary
number of packets containing other metadata headers,
followed by a flush packet.
We don't currently recognize any other metadata headers, so
we just parse through any extra packets,
will.
As a result, fetch-pack hangs, waiting for input. However,
remote-curl believes it has sent all of the advertisement,
and therefore waits for fetch-pack to speak. The two
processes end up in a deadlock.
This fortunately doesn't happen in the normal fetching
workflow, because git-fetch first uses the list
Paul Gortmaker paul.gortma...@windriver.com writes:
Currently, if you don't have curl installed, you will get
$ make distclean 21 | grep curl
/bin/sh: curl-config: not found
/bin/sh: curl-config: not found
/bin/sh: curl-config: not found
/bin/sh: curl-config: not found
;
+ gzip_size = stream.total_out;
headers = curl_slist_append(headers, Content-Encoding: gzip);
curl_easy_setopt(slot-curl, CURLOPT_POSTFIELDS, gzip_body);
- curl_easy_setopt(slot-curl, CURLOPT_POSTFIELDSIZE, size
:);
+
+retry:
slot = get_active_slot();
curl_easy_setopt(slot-curl, CURLOPT_NOBODY, 0);
@@ -451,10 +456,6 @@ static int post_rpc(struct rpc_state *rpc)
curl_easy_setopt(slot-curl, CURLOPT_URL, rpc-service_url);
curl_easy_setopt(slot-curl, CURLOPT_ENCODING
When we get an http 401, we prompt for credentials and put
them in our global credential struct. We also feed them to
the curl handle that produced the 401, with the intent that
they will be used on a retry.
When the code was originally introduced in commit 42653c0,
this was a necessary step
and put
them in our global credential struct. We also feed them to
the curl handle that produced the 401, with the intent that
they will be used on a retry.
When the code was originally introduced in commit 42653c0,
this was a necessary step. However, since dfa1725, we always
feed our global
attractive minimalistic way to go forward. We
can always add per-remote configuration when we find it necessary,
but once we add support, we cannot easily yank it out.
Like this?
Yeah. Will queue this one instead. The simpler, the better ;-)
-- 8 --
Subject: [PATCH] remote-curl: let users turn
On Fri, Sep 21, 2012 at 10:34:22AM -0700, Junio C Hamano wrote:
I'm half-tempted to just drop the config entirely, leave
GIT_SMART_HTTP=false as an escape hatch, and see if anybody even cares.
Sounds like a very attractive minimalistic way to go forward. We
can always add per-remote
We don't actually care whether the connection is http or
not; what we care about is whether it might be smart http.
Rename the variable to be more accurate, which will make it
easier to later make smart-http optional.
Signed-off-by: Jeff King p...@peff.net
---
remote-curl.c | 6 +++---
1 file
Usually there is no need for users to specify whether an
http remote is smart or dumb; the protocol is designed so
that a single initial request is made, and the client can
determine the server's capability from the response.
However, some misconfigured dumb-only servers may not like
the initial
On Thu, Sep 20, 2012 at 10:53:15AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I added the config item as remote.foo.smarthttp. You could also allow
http.$url.smart (and just http.smart, for that matter), which could
be more flexible if you have multiple remotes pointing
Jeff King p...@peff.net writes:
On Thu, Sep 20, 2012 at 10:53:15AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I added the config item as remote.foo.smarthttp. You could also allow
http.$url.smart (and just http.smart, for that matter), which could
be more flexible if
Jeff King p...@peff.net writes:
I'm half-tempted to just drop the config entirely, leave
GIT_SMART_HTTP=false as an escape hatch, and see if anybody even cares.
Sounds like a very attractive minimalistic way to go forward. We
can always add per-remote configuration when we find it necessary,
. We
can always add per-remote configuration when we find it necessary,
but once we add support, we cannot easily yank it out.
Like this?
-- 8 --
Subject: [PATCH] remote-curl: let users turn off smart http
Usually there is no need for users to specify whether an
http remote is smart or dumb
Introduce http.$url_prefix.dumbhttpfallback configuration variables
so that users do not have to set GIT_DUMB_HTTP_FALLBACK environment
depending on which remote they are talking with.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
remote-curl.c | 53
This reverts be22d92 (http: avoid empty error messages for some curl errors,
2011-09-05) on platforms with older versions of libcURL.
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
Resend, regardless that Junio said this not to be needed, as I don't see it
applied yet.
Also tried
From: Joachim Schmitz [mailto:j...@schmitz-digital.de]
Sent: Wednesday, August 22, 2012 11:06 PM
To: 'Junio C Hamano'
Cc: 'git@vger.kernel.org'
Subject: RE: [PATCH] Don't use curl_easy_strerror prior to curl-7.12.0
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Wednesday, August
Joachim Schmitz j...@schmitz-digital.de writes:
From: Joachim Schmitz [mailto:j...@schmitz-digital.de]
Sent: Wednesday, August 22, 2012 11:06 PM
To: 'Junio C Hamano'
Cc: 'git@vger.kernel.org'
Subject: RE: [PATCH] Don't use curl_easy_strerror prior to curl-7.12.0
From: Junio C Hamano
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Thursday, August 23, 2012 11:27 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Don't use curl_easy_strerror prior to curl-7.12.0
Joachim Schmitz j...@schmitz-digital.de writes:
From: Joachim Schmitz [mailto:j
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
http.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/http.c b/http.c
index b61ac85..18bc6bf 100644
--- a/http.c
+++ b/http.c
@@ -806,10 +806,12 @@ static int http_request(const char *url, void *result,
int target, int options)
Joachim Schmitz j...@schmitz-digital.de writes:
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
At the very least, please mention that this reverts be22d92 (http:
avoid empty error messages for some curl errors, 2011-09-05) on
platforms with older versions of libcURL.
---
http.c | 2
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Wednesday, August 22, 2012 7:19 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Don't use curl_easy_strerror prior to curl-7.12.0
Joachim Schmitz j...@schmitz-digital.de writes:
Signed-off-by: Joachim Schmitz j
Joachim Schmitz j...@schmitz-digital.de writes:
Like this:
This reverts be22d92 (http: avoid empty error messages for some curl errors,
2011-09-05) on platforms with older versions of libcURL.
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
Perfect ;-)
http.c | 2
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Wednesday, August 22, 2012 7:41 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Don't use curl_easy_strerror prior to curl-7.12.0
Joachim Schmitz j...@schmitz-digital.de writes:
Like this:
This reverts
Joachim Schmitz j...@schmitz-digital.de writes:
This reverts be22d92 (http: avoid empty error messages for some curl errors,
2011-09-05) on platforms with older versions of libcURL.
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
http.c | 2 ++
1 file changed, 2 insertions
-Original Message-
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Wednesday, August 22, 2012 8:17 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Don't use curl_easy_strerror prior to curl-7.12.0
Joachim Schmitz j...@schmitz-digital.de writes
Joachim Schmitz j...@schmitz-digital.de writes:
diff --git a/http.c b/http.c
index b61ac85..18bc6bf 100644
--- a/http.c
+++ b/http.c
@@ -806,10 +806,12 @@ static int http_request(const char *url, void
*result, int target, int options)
Likewrapped X-
Any suggestion?
Other than
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Wednesday, August 22, 2012 11:02 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Don't use curl_easy_strerror prior to curl-7.12.0
Joachim Schmitz j...@schmitz-digital.de writes:
diff --git a/http.c b/http.c
Some http servers return an HTML error page and git reads it as normal
data. Adding -f option makes curl fail silently.
Signed-off-by: Catalin Marinas [EMAIL PROTECTED]
---
git-clone-dumb-http |2 +-
git-fetch-script |2 +-
git-ls-remote-script |2 +-
3 files changed, 3
Not just libcurl, but now we require curl executable as well.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
INSTALL |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
b300e6d28fc160ddc6685bde96b6bc9a710e01c3
diff --git a/INSTALL b/INSTALL
--- a/INSTALL
+++ b/INSTALL
@@ -41,8
[EMAIL PROTECTED] (Darrin Thompson) writes:
Cause setting environment variable GIT_SSL_NO_VERIFY to turn off
curl's ssl peer verification.
Only use curl for http transfers, instead of curl and wget.
I do not mind curl per se, since we already require libcurl for
http-pull, but it would
401 - 491 of 491 matches
Mail list logo
