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
> On Mar 11, 2015, at 5:59 PM, brian m. carlson
> 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
>>> wrote:
>>> Does it work with a ticket if you specify a username, as in the
>>> following URL?
>>> https://
f I have a valid ticket, why am I being prompted for credentials?
>
> libcurl won't even attempt authentication if you don't have a username
> specified. I know that the web server should be able to figure it out
> from your credentials, so it shouldn't matter what user
> On Feb 25, 2015, at 3:59 PM, Dan Langille (dalangil)
> wrote:
>
>> On Feb 24, 2015, at 4:03 PM, Dan Langille (dalangil)
>> wrote:
>>
>>> On Feb 19, 2015, at 3:35 PM, brian m. carlson
>>> wrote:
>>>
>>> On Wed, Feb 18, 2015 at 04:17:46PM +, Dan Langille (dalangil) wrote:
I just b
On Wed, Mar 11, 2015 at 07:33:05PM +, Dan Langille (dalangil) wrote:
On Mar 10, 2015, at 6:29 PM, brian m. carlson
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
Yes, that does work. Our proj
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 cr
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 requeste
> On Feb 24, 2015, at 4:03 PM, Dan Langille (dalangil)
> wrote:
>
>> On Feb 19, 2015, at 3:35 PM, brian m. carlson
>> 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://g
> On Feb 19, 2015, at 3:35 PM, brian m. carlson
> 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 ~/src/git/git clon
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
On Feb 17, 2015, at 6:36 PM, Junio C Hamano wrote:
>
> "Dan Langille (dalangil)" writes:
>
>>> On Jan 20, 2015, at 7:22 PM, Junio C Hamano wrote:
>>>
>>> "Dan Langille (dalangil)" writes:
>>>
I did not test this patch. Is that holding up a commit?
>>>
>>> I am hoping that you rebuilt
"Dan Langille (dalangil)" writes:
>> On Jan 20, 2015, at 7:22 PM, Junio C Hamano wrote:
>>
>> "Dan Langille (dalangil)" 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 mess
> On Jan 20, 2015, at 7:22 PM, Junio C Hamano wrote:
>
> "Dan Langille (dalangil)" 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 i
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
---
RHEL3 ships with curl
= 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/nul
RL_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
OGRAM_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
= 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
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
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
> On Jan 20, 2015, at 7:22 PM, Junio C Hamano wrote:
>
> "Dan Langille (dalangil)" 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 i
"Dan Langille (dalangil)" 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 queued on the 'next'
ssword_required;
> +#ifdef 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_reque
igned 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);
curl_easy_seto
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. Rig
> On Jan 6, 2015, at 10:31 AM, Dan Langille (dalangil)
> wrote:
>
> On Jan 5, 2015, at 6:53 PM, brian m. carlson
> 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
> On Jan 6, 2015, at 10:31 AM, Dan Langille (dalangil)
> wrote:
>
> On Jan 5, 2015, at 6:53 PM, brian m. carlson
> 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
On Jan 5, 2015, at 6:53 PM, brian m. carlson
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 the client side, corr
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 list
content_type(struct strbuf *raw,
> struct strbuf *type,
> strbuf_addstr(charset, "ISO-8859-1");
> }
>
> +void disable_passwordless_auth(struct active_request_slot *slot)
> +{
> +#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
> +#define HTTP_AUTH_PASSWORD
nt_type(struct strbuf *raw,
> struct strbuf *type,
> 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
gt; 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
> reroll. I'll need your sign-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
n-password-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_OPTIONA
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
arset, "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 & ~
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
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 a
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 authentica
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 Ne
L_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_R
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
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
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
Acked-by: Eric Faye-Lund
---
config.mak.uname | 2 --
1 file changed, 2 deletions(-)
diff --git a/config.mak.uname b
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
Acked-by: Eric Faye-Lund
---
config.mak.uname | 2 --
1 file changed, 2 deletions(-)
diff --git a/config.mak.uname b
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
Acked-by: Eric Faye-Lund
---
config.mak.uname | 2 --
1 file changed, 2 deletions(-)
diff --git a/config.mak.uname b
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
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 th
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
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
es not exist).
Nitpick, 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
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
Simplify cases where a strbuf_reset is immediately followed by a
strbuf_add by using strbuf_set operations.
Signed-off-by: Jeremiah Mahler
---
remote-curl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 4493b38..49d27f5 100644
--- a/rem
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 expo
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
---
remote-curl.c
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 v
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
> recogn
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 allow
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
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
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" w
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
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
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 c
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
---
remo
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-by
Am 05.05.2014 12:53, schrieb Erik Faye-Lund:
> On Wed, Apr 30, 2014 at 9:46 PM, Sebastian Schuberth
> wrote:
>> On Wed, Apr 30, 2014 at 6:52 PM, Johannes Schindelin
>> wrote:
>>
We can keep this patch in the msysGit repo for the 2.0 release.
>>>
>>> FWIW the plan is to switch to mingwGitDevE
On Mon, May 5, 2014 at 12:53 PM, Erik Faye-Lund 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
>> Windows.
On Wed, Apr 30, 2014 at 9:46 PM, Sebastian Schuberth
wrote:
> On Wed, Apr 30, 2014 at 6:52 PM, Johannes Schindelin
> 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
On Wed, Apr 30, 2014 at 6:52 PM, Johannes Schindelin
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.
The environm
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 unsubs
On Wed, Apr 30, 2014 at 5:27 PM, Junio C Hamano wrote:
> Erik Faye-Lund 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 is
On Wed, Apr 30, 2014 at 8:27 AM, Junio C Hamano 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 reported can be
Erik Faye-Lund 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 autoconf-
On Mon, Apr 28, 2014 at 6:29 PM, Erik Faye-Lund 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 it
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
Acked-by: Eric Faye-Lund
---
config.mak.uname | 2 --
1 file changed, 2 deletions(-)
diff --git a/config.mak.uname b
Junio C Hamano 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=""
> Emp
shell $(CURL_CONFIG) --libs) assigned an
> empty string 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 be
On Mon, Apr 28, 2014 at 12:44 PM, Jonathan Nieder 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 an
ifdef CURLDIR
> + CURL_LIBCURL=
> else
> + CURL_CONFIG ?= curl-config
> + ifeq "$(CURL_CONFIG)" ""
> + CURL_LIBCURL =
> + else
> + CURL_LIBCURL := $(shell $(CU
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 o
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.
Allow overriding CURL_CONFIG to a custom path to curl-config, to
compile against a curl installation other
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
On Mon, Apr 28, 2014 at 6:23 PM, Marat Radchenko 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
>> wrote:
>> > Also, fix `warning: passing argument 2 of 'mingw_main' from
>> > incompatible pointer type` in http-fetch.c
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
> 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, perh
On Mon, Apr 28, 2014 at 3:51 PM, Marat Radchenko 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 this list: send the lin
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
---
config.mak.uname | 2 --
http-fetch.c | 5 +++--
remote-curl.c| 2 +-
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git
Dave Borowitz 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
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
On Mon, Apr 14, 2014 at 4:22 PM, Junio C Hamano wrote:
> Dave Borowitz 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
Dave Borowitz 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 to
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
---
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
--- a/compat/vcbuild/scri
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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
+++ b/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 i
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.
Signed-off-by: Jeff King
---
I really am just cargo-culting here. I have no idea what
multi->closure_handle
'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 d
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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
+++ b/builtin/fetch-pack.c
@@
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
>
From: brian m. carlson
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
401 - 500 of 577 matches
Mail list logo
