Re: clone vs submodule operation with HTTP cURL

bmodule, git seems to > be managing cURL differently. cURL drop the ball quickly. > > Example (No other setup needed on the client) : > git clone HTTPrepo -> GET -> 401 -> GET -> 401 -> GET (this time with > Authorization: Negotiate) -> 200 OK > > git

clone vs submodule operation with HTTP cURL

Hello everyone, In our usage of GSSAPI via HTTPS, all our operation with git are very well handle, however, when trying to update a submodule, git seems to be managing cURL differently. cURL drop the ball quickly. Example (No other setup needed on the client) : git clone HTTPrepo -> GET -&g

Re: [RFC] dropping support for ancient versions of curl

rst patch that removes a lot of the really questionable bits > (like silently ignoring security-related features). I do not have problems with setting cut-off at 7.11.0; I do not foresee anybody who actively maintains a port for a platform whose cURL is older than that version would step up ;-) Thanks.

Re: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0

l get >> something wrong (especially without braces, it's not immediately clear >> that both sides are a single statement). >> >> I wonder if it would be more readable to do something like: >> >> #if LIBCURL_VERSION_NUM < 0x070c00 >> static const cha

Re: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0

re a single statement). > > I wonder if it would be more readable to do something like: > > #if LIBCURL_VERSION_NUM < 0x070c00 > static const char *curl_easy_strerror(CURL *curl) > { > return "[error code unavailable; curl version too old]"; > } &

Re: [RFC] dropping support for ancient versions of curl

hows that yes, it's convenient when old libraries are supported. I don't dispute that. But one of my earlier points is that this isn't just about maintenance burden (which I agree is not huge); it's about whether we do a disservice to users to pretend that Git is even remotely tested with older v

Re: [RFC] dropping support for ancient versions of curl

Hi Peff, On Thu, 6 Apr 2017, Jeff King wrote: > And it's not like people on ancient mission-critical systems get cut > off. They can still run the version of Git they were running when their > OS went out of support. You keep baiting me, so I'll bite, after resisting the urge for so long. Let

Re: [RFC] dropping support for ancient versions of curl

now as I'm busy converting machines from el5 to el7. > > > > Thanks for sharing, that's a really interesting data point. > > > > I'm not quite sure what to take away from it, though. Either "yes, > > somebody really is using Git with antique versions of curl&quo

Re: [RFC] dropping support for ancient versions of curl

point. I'm not quite sure what to take away from it, though. Either "yes, somebody really is using Git with antique versions of curl". Or "even the antique people are giving up el4, and it might be reasonable to start requiring curl >= 7.11.0". I do not know of anyone wh

Re: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0

On Wed, Apr 05, 2017 at 03:04:24PM +0200, Tom G. Christensen wrote: > Commit 17966c0a added an unguarded use of curl_easy_strerror. > This adds a guard so it is not used with curl < 7.12.0. > > Signed-off-by: Tom G. Christensen <t...@jupiterrise.com> > --- > http.c |

Re: [RFC] dropping support for ancient versions of curl

.com/jrpms/ (for el3,el4,el5) > https://jupiterrise.com/jrpmsplus/ (for el6, el7) > > They are built against system versions of curl though a few patches are > required for 7.10.6 (el3) and 7.12.1 (el4) support. > Patches can be found in the src.rpm, though I can also post them here

Re: [RFC] dropping support for ancient versions of curl

On Thu, Apr 06, 2017 at 12:53:01AM +, brian m. carlson wrote: > > It would be great to have them on-list, as far as I can tell they were > > never submitted? Is there some time/administrative reason for why > > you're not submitting them? Some of these are many years old, it would > > be

Re: [RFC] dropping support for ancient versions of curl

8 Mar 2016 09:31:56 +0100 Subject: [PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7 Date: Tue, 23 Aug 2016 10:32:51 +0200 Subject: [PATCH 5/7] Add support for gnupg < 1.4 Date: Tue, 23 Aug 2016 18:15:13 +0200 Subject: [PATCH 6/7] Handle missing CURLINFO_SSL_DATA_{IN,OUT} Date:

Re: [RFC] dropping support for ancient versions of curl

py to be used with Python 2.2 > Date: Tue, 8 Mar 2016 09:31:56 +0100 > Subject: [PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7 > Date: Tue, 23 Aug 2016 10:32:51 +0200 > Subject: [PATCH 5/7] Add support for gnupg < 1.4 > Date: Tue, 23 Aug 2016 18:15:13 +0200 > Subj

Re: [PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7

On 2017-04-05 15:50, Ævar Arnfjörð Bjarmason wrote: > This effectively disables that code & this later check: > > + if (results->http_connectcode == 407) > + credential_reject(_auth); > > What's the impact of not taking that branch when the proxy returns a

Re: [PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7

On Wed, Apr 5, 2017 at 3:04 PM, Tom G. Christensen <t...@jupiterrise.com> wrote: > With curl < 7.10.7 we cannot get the proxy CONNECT response code. > As a workaround set it to zero which means no response code available. CC-ing Knut Franke <k.fra...@science-computing.de>

Re: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0

On Wed, Apr 5, 2017 at 3:04 PM, Tom G. Christensen <t...@jupiterrise.com> wrote: > Commit 17966c0a added an unguarded use of curl_easy_strerror. > This adds a guard so it is not used with curl < 7.12.0. Looks good to me. Eric Wong added this in 17966c0a63. > Signed-off-by: Tom

Re: [RFC] dropping support for ancient versions of curl

11:02:02 +0200 Subject: [PATCH 2/7] Install man pages when NO_PERL_MAKEMAKER is used Date: Mon, 22 Sep 2014 13:42:50 +0200 Subject: [PATCH 3/7] Allow svnrdump_sim.py to be used with Python 2.2 Date: Tue, 8 Mar 2016 09:31:56 +0100 Subject: [PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7 D

[PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0

Commit 17966c0a added an unguarded use of curl_easy_strerror. This adds a guard so it is not used with curl < 7.12.0. Signed-off-by: Tom G. Christensen <t...@jupiterrise.com> --- http.c | 4 1 file changed, 4 insertions(+) diff --git a/http.c b/http.c index a46ab23af..104caaa

[PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7

With curl < 7.10.7 we cannot get the proxy CONNECT response code. As a workaround set it to zero which means no response code available. Signed-off-by: Tom G. Christensen <t...@jupiterrise.com> --- http.c | 4 1 file changed, 4 insertions(+) diff --git a/http.c b/http.c index

Re: [RFC] dropping support for ancient versions of curl

On Wed, Apr 5, 2017 at 11:33 AM, Tom G. Christensen <t...@jupiterrise.com> wrote: > On 04/04/17 04:54, Jeff King wrote: >> >> A nearby thread raised the question of whether we can rely on a version >> of libcurl that contains a particular feature. The version in questi

Re: [RFC] dropping support for ancient versions of curl

On 04/04/17 04:54, Jeff King wrote: A nearby thread raised the question of whether we can rely on a version of libcurl that contains a particular feature. The version in question is curl 7.11.1, which came out in March 2004. My feeling is that this is old enough to stop caring about. Which

Re: [RFC] dropping support for ancient versions of curl

a couple of lines. It's remembering to check and #ifdef new lines that get added, too (this conversation started because of review on another patch which failed to do so). Is our attitude "add it and when somebody with an ancient curl complains and provides a patch, we'll #ifdef it"? -Peff

Re: [RFC] dropping support for ancient versions of curl

ree that we can't > >> expect the world to be running the most up-to-date version of curl > >> but we should be able to select some "oldest" version we will support > >> which can be bumped up every couple of years. > >> > >> I mean, ensuring

Re: [RFC] dropping support for ancient versions of curl

On 04/05, Johannes Schindelin wrote: > Hi Brandon, > > On Tue, 4 Apr 2017, Brandon Williams wrote: > > > I'm all for seeing a patch like this applied. I agree that we can't > > expect the world to be running the most up-to-date version of curl but > > we should

Re: [RFC] dropping support for ancient versions of curl

On Tue, Apr 4, 2017 at 3:46 PM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Brandon, > > On Tue, 4 Apr 2017, Brandon Williams wrote: > >> I'm all for seeing a patch like this applied. I agree that we can't >> expect the world to be running the m

Re: [RFC] dropping support for ancient versions of curl

Hi Brandon, On Tue, 4 Apr 2017, Brandon Williams wrote: > I'm all for seeing a patch like this applied. I agree that we can't > expect the world to be running the most up-to-date version of curl but > we should be able to select some "oldest" version we will support which

Re: [RFC] dropping support for ancient versions of curl

(but was too lazy to actually build an ancient version of curl -- thank you, Frank). In this case it was a compile error, which was obvious. I'm much more worried about subtle interactions, or the fact that some of the ifdefs are around security features that get ignored. In some cases we at least iss

Re: [RFC] dropping support for ancient versions of curl

ckage a newer libcurl as well. > > > > But how much maintenance burden is it, really? Is the continued use of > > those #ifdef's really worth this much discussion, let alone applying a > > patch that may break users who have so far been happy? > > > > It would be a d

Re: [RFC] dropping support for ancient versions of curl

use of > those #ifdef's really worth this much discussion, let alone applying a > patch that may break users who have so far been happy? > > It would be a different thing if we had to have hacks to support old cURL > versions, where we need to ship entire >10kB source files

Re: [RFC] dropping support for ancient versions of curl

On Mon, Apr 03, 2017 at 10:54:38PM -0400, Jeff King wrote: > A nearby thread raised the question of whether we can rely on a version > of libcurl that contains a particular feature. The version in question > is curl 7.11.1, which came out in March 2004. I had a quick look at the 7.11.

Re: [RFC] dropping support for ancient versions of curl

uld be a different thing if we had to have hacks to support old cURL versions, where we need to ship entire >10kB source files that tap into internal data structures that may, or may not have changed. Such a hack, I would be happy to discuss when we could possibly remove it. But a couple of #ifdef'

Re: [RFC] dropping support for ancient versions of curl

caring about. Which means >> > we can drop some of the #ifdefs that clutter the HTTP code (and there's >> > a patch at the end of this mail dropping support for everything older >> > than 7.11.1). But that made wonder: how old is too old? I think it's >> > nice tha

Re: [RFC] dropping support for ancient versions of curl

TTP code (and there's > > a patch at the end of this mail dropping support for everything older > > than 7.11.1). But that made wonder: how old is too old? I think it's > > nice that we don't force people to upgrade to the latest version of > > curl. But at some point, if you are

Re: [RFC] dropping support for ancient versions of curl

r > than 7.11.1). But that made wonder: how old is too old? I think it's > nice that we don't force people to upgrade to the latest version of > curl. But at some point, if you are running a 13-year-old version of > libcurl, how likely are you to run a brand new version of Git? :

Re: [RFC] dropping support for ancient versions of curl

d probably start looking at what long-term distros > like RHEL are still shipping and supporting. Hi Peff, I am all for making code simpler and dropping ancient versions. I think we have to look at about the 7.19.1 mark. I can confirm on my Centos 6.8 machine and on RHEL 6.8 on the client side curl

Re: [RFC] dropping support for ancient versions of curl

number of curl sessions (counted across slots) to be kept across requests. They will not be ended with curl_easy_cleanup() until - http_cleanup() is invoked. If USE_CURL_MULTI is not defined, this - value will be capped at 1. Defaults to 1. + http_cleanup() is invoked. De

[RFC] dropping support for ancient versions of curl

A nearby thread raised the question of whether we can rely on a version of libcurl that contains a particular feature. The version in question is curl 7.11.1, which came out in March 2004. My feeling is that this is old enough to stop caring about. Which means we can drop some of the #ifdefs

[PATCH v2 2/2] remote-curl: allow push options

Teach remote-curl to understand push options and to be able to convey them across HTTP. Signed-off-by: Brandon Williams <bmw...@google.com> --- Documentation/git-send-pack.txt | 6 ++ builtin/send-pack.c | 5 + remote-curl.c | 8 t/t554

Re: [PATCH 2/2] remote-curl: allow push options

On 03/22, Jonathan Nieder wrote: I agree with most of these changes, I'll make them locally and send out a reroll. > Brandon Williams wrote: > > > --- a/builtin/send-pack.c > > +++ b/builtin/send-pack.c > > @@ -152,6 +152,7 @@ int cmd_send_pack(int argc, const char **argv, const > > char

Re: [PATCH 2/2] remote-curl: allow push options

Brandon Williams wrote: > --- a/builtin/send-pack.c > +++ b/builtin/send-pack.c > @@ -152,6 +152,7 @@ int cmd_send_pack(int argc, const char **argv, const char > *prefix) > int progress = -1; > int from_stdin = 0; > struct push_cas_option cas = {0}; > + struct string_list

Re: [PATCH 2/2] remote-curl: allow push options

On 03/22, Junio C Hamano wrote: > Brandon Williams <bmw...@google.com> writes: > > > Teach remote-curl to understand push options and to be able to convey > > them across HTTP. > > > > Signed-off-by: Brandon Williams <bmw...@google.com> > > --- &g

Re: [PATCH 2/2] remote-curl: allow push options

Brandon Williams <bmw...@google.com> writes: > Teach remote-curl to understand push options and to be able to convey > them across HTTP. > > Signed-off-by: Brandon Williams <bmw...@google.com> > --- An earlier 438fc684 ("push options: pass push options to the tra

[PATCH 2/2] remote-curl: allow push options

Teach remote-curl to understand push options and to be able to convey them across HTTP. Signed-off-by: Brandon Williams <bmw...@google.com> --- builtin/send-pack.c | 5 + remote-curl.c | 8 t/t5545-push-options.sh | 30 +- 3 files c

[PATCH v10 4/6] http: create function to get curl allowed protocols

--- 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/http.c b/http.c index 034426e..f7c488a 100644 --- a/http.c +++ b/http.c @@ -489,10 +489,25 @@ static void set_curl_keepalive(CURL *c) } #endif +static long get_curl_allowed_protocols(void) +{ + long allowed_protoco

Re: [PATCH v9 4/5] http: create function to get curl allowed protocols

On 12/14, Jeff King wrote: > On Tue, Dec 13, 2016 at 05:40:36PM -0800, Brandon Williams wrote: > > > Move the creation of an allowed protocols whitelist to a helper > > function. > > This is "what" but not "why". You can figure it out if you see the next > patch, but it's often nice to make a

Re: [PATCH v9 4/5] http: create function to get curl allowed protocols

On Tue, Dec 13, 2016 at 05:40:36PM -0800, Brandon Williams wrote: > Move the creation of an allowed protocols whitelist to a helper > function. This is "what" but not "why". You can figure it out if you see the next patch, but it's often nice to make a brief mention, like: This will be useful

[PATCH v9 4/5] http: create function to get curl allowed protocols

100644 --- a/http.c +++ b/http.c @@ -489,10 +489,25 @@ static void set_curl_keepalive(CURL *c) } #endif +static long get_curl_allowed_protocols(void) +{ + long allowed_protocols = 0; + + if (is_transport_allowed("http")) + allowed_protocols |

[PATCH v2 3/6] remote-curl: rename shadowed options variable

The discover_refs() function has a local "options" variable to hold the http_get_options we pass to http_get_strbuf(). But this shadows the global "struct options" that holds our program-level options, which cannot be accessed from this function. Let's give the local one a more descriptive name

[PATCH v8 4/5] http: create function to get curl allowed protocols

http.c +++ b/http.c @@ -624,11 +624,25 @@ void setup_curl_trace(CURL *handle) curl_easy_setopt(handle, CURLOPT_DEBUGDATA, NULL); } +static long get_curl_allowed_protocols(void) +{ + long allowed_protocols = 0; + + if (is_transport_allowed("http")) + a

[PATCH 3/6] remote-curl: rename shadowed options variable

The discover_refs() function has a local "options" variable to hold the http_get_options we pass to http_get_strbuf(). But this shadows the global "struct options" that holds our program-level options, which cannot be accessed from this function. Let's give the local one a more descriptive name

Re: [PATCH v3] remote-curl: don't hang when a server dies before any output

> > One case where this happens is when attempting to fetch a dangling > object by SHA. In this case, the server dies before sending any data. > Prior to this patch, fetch-pack would wait for data from the server, > and remote-curl would wait for fetch-pack, causing a deadlock. > ... >

[PATCH v3] remote-curl: don't hang when a server dies before any output

. In this case, the server dies before sending any data. Prior to this patch, fetch-pack would wait for data from the server, and remote-curl would wait for fetch-pack, causing a deadlock. Despite this patch, there is other possible malformed input that could cause the same deadlock (e.g. a half

Re: [PATCH v2] remote-curl: don't hang when a server dies before any output

> > One case where this happens is when attempting to fetch a dangling > object by SHA. > > Prior to this patch, fetch-pack would wait for more data from the > server, and remote-curl would wait for fetch-pack, causing a deadlock. > > Despite this patch, there is other possible m

Re: [PATCH] remote-curl: don't hang when a server dies before any output

Jeff King writes: > So I don't feel like we have a good patch for the general case yet, and > I'm probably not going to get around to implementing it anytime soon. So > I'd suggest taking David's original patch (to punt when the response is > empty) in the meantime. Yup, we are

[PATCH v2] remote-curl: don't hang when a server dies before any output

. Prior to this patch, fetch-pack would wait for more data from the server, and remote-curl would wait for fetch-pack, causing a deadlock. Despite this patch, there is other possible malformed input that could cause the same deadlock (e.g. a half-finished pktline, or a pktline but no trailing flush

RE: [PATCH] remote-curl: don't hang when a server dies before any output

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Friday, November 18, 2016 12:09 PM > To: David Turner > Cc: Junio C Hamano; git@vger.kernel.org; spea...@spearce.org > Subject: Re: [PATCH] remote-curl: don't hang when a server dies before any &g

Re: [PATCH] remote-curl: don't hang when a server dies before any output

t/have negotiation takes multiple rounds, the intermediate rounds don't end on a flush packet, and my patch causes remote-curl to complain that the response was truncated. I think you could fix it by teaching remote-curl that the final packet must be a flush _or_ contain an ACK/NAK, but I didn't try

RE: [PATCH] remote-curl: don't hang when a server dies before any output

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Friday, November 18, 2016 12:02 PM > To: Junio C Hamano > Cc: David Turner; git@vger.kernel.org; spea...@spearce.org > Subject: Re: [PATCH] remote-curl: don't hang when a server dies before any > ou

Re: [PATCH] remote-curl: don't hang when a server dies before any output

On Tue, Nov 15, 2016 at 09:42:57AM -0800, Junio C Hamano wrote: > >> Hmph. I think I tried David's original under GIT_TEST_LONG and saw > >> it got stuck; could be the same issue, I guess. > > > > It works OK here. I think it is just that the test is really slow (by > > design). > > Yeah, I

Re: [PATCH] remote-curl: don't hang when a server dies before any output

Jeff King writes: > On Mon, Nov 14, 2016 at 05:02:27PM -0800, Junio C Hamano wrote: > >> Jeff King writes: >> >> > Actually, I take it back. I think it works for a single round of ref >> > negotiation, but not for multiple. Enabling GIT_TEST_LONG=1 causes it to >>

RE: [PATCH] remote-curl: don't hang when a server dies before any output

> -Original Message- > From: Jeff King [mailto:p...@peff.net] ... > I'll make that change and then try to wrap this up with a commit message. > I plan to steal your tests, if that's OK. Please do!

Re: [PATCH] remote-curl: don't hang when a server dies before any output

On Mon, Nov 14, 2016 at 05:02:27PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Actually, I take it back. I think it works for a single round of ref > > negotiation, but not for multiple. Enabling GIT_TEST_LONG=1 causes it to > > fail t5551. > > > > I think I've

Re: [PATCH] remote-curl: don't hang when a server dies before any output

tocol we will see a flush packet (and perhaps that is a sign that > this protocol-snooping approach is not a good one). Yep, that is it. The server may end with an ACK or a NAK, not a flush packet. So going this route really does mean teaching remote-curl a lot more about the protocol, which is pretty

Re: [PATCH] remote-curl: don't hang when a server dies before any output

Jeff King writes: > Actually, I take it back. I think it works for a single round of ref > negotiation, but not for multiple. Enabling GIT_TEST_LONG=1 causes it to > fail t5551. > > I think I've probably made a mis-assumption on exactly when in the HTTP > protocol we will see a

Re: [PATCH] remote-curl: don't hang when a server dies before any output

On Mon, Nov 14, 2016 at 02:40:49PM -0500, Jeff King wrote: > On Mon, Nov 14, 2016 at 01:24:31PM -0500, Jeff King wrote: > > > 2. Have remote-curl understand enough of the protocol that it can > > abort rather than hang. > > > > I think that's effectiv

Re: [PATCH] remote-curl: don't hang when a server dies before any output

On Mon, Nov 14, 2016 at 11:25:30PM +, David Turner wrote: > > But it does seem to work. At least it doesn't seem to break anything > > in the test suite, and it fixes the new tests you added. I'd worry > > that there's some obscure case where the response isn't packetized > > in the same way.

RE: [PATCH] remote-curl: don't hang when a server dies before any output

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Monday, November 14, 2016 2:41 PM > To: David Turner > Cc: git@vger.kernel.org; spea...@spearce.org > Subject: Re: [PATCH] remote-curl: don't hang when a server dies before any > output > > On

Re: [PATCH] remote-curl: don't hang when a server dies before any output

On Mon, Nov 14, 2016 at 01:19:49PM -0800, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > So something like this. It turned out to be a lot uglier than I had > > hoped because we get fed the data from curl in odd-sized chunks, so we

Re: [PATCH] remote-curl: don't hang when a server dies before any output

Jeff King <p...@peff.net> writes: > So something like this. It turned out to be a lot uglier than I had > hoped because we get fed the data from curl in odd-sized chunks, so we > need a state machine. It is unfortunate that we have to snoop the protocol like this to infer an

Re: [PATCH] remote-curl: don't hang when a server dies before any output

On Mon, Nov 14, 2016 at 01:24:31PM -0500, Jeff King wrote: > 2. Have remote-curl understand enough of the protocol that it can > abort rather than hang. > > I think that's effectively the approach of your patch, but for one > specific case. But could we, for exa

Re: [PATCH] remote-curl: don't hang when a server dies before any output

I agree we don't want to hang forever, but this leaves open the question: what is hanging? My guess is that fetch-pack is waiting for more data from the server, and remote-curl is waiting for fetch-pack to tell us what to send for the next request. Neither will make forward prog

[PATCH] remote-curl: don't hang when a server dies before any output

t_rpc(struct rpc_state *rpc) curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, rpc_in); curl_easy_setopt(slot->curl, CURLOPT_FILE, rpc); + + rpc->any_written = 0; err = run_slot(slot, NULL); if (err == HTTP_REAUTH && !large_request)

Re: [PATCH 04/11] Resumable clone: add prime-clone to remote-curl

On Mon, Sep 19, 2016 at 08:52:34PM +0700, Duy Nguyen wrote: > > A brief overview for this service in > Documentation/technical/http-protocol.txt (and maybe > Documentation/gitremote-helpers.txt as well) would be great help. It's > a bit hard to follow because at this point I don't know anything

Re: [PATCH 07/11] Resumable clone: add resumable download to http/curl

ept isn't fleshed out enough, even theoretically--containing only the element of retrying with some very basic components to those decisions. I think that this will ultimately require fishing through other examples of resumable downloads (which was very painful to read when I tried). I know curl ha

Re: [PATCH 04/11] Resumable clone: add prime-clone to remote-curl

On Fri, Sep 16, 2016 at 7:12 AM, Kevin Wern wrote: > +static void prime_clone(void) > +{ > + char *result, *result_full, *line; > + size_t result_len; > + int err = 0, one_successful = 0; > + > + if (request_service("git-prime-clone", _full, , > +

Re: [PATCH 07/11] Resumable clone: add resumable download to http/curl

Kevin Wern writes: > +int http_download_primer(const char *url, const char *out_file) > +{ > + int ret = 0, try_count = HTTP_TRY_COUNT; > + struct http_get_options options = {0}; > + options.progress = 1; > + > + if (file_exists(out_file)) { > +

[PATCH 07/11] Resumable clone: add resumable download to http/curl

will be downloaded to. The url passed to remote-curl on invocation does not matter (git clone will use the resource url again here). Signed-off-by: Kevin Wern <kevin.m.w...@gmail.com> --- http.c| 86 ++- http.h| 7 - remote-curl.

[PATCH 04/11] Resumable clone: add prime-clone to remote-curl

Add function and interface to handle prime-clone input, extracting and using duplicate functionality from discover_refs as function request_service. Because part of our goal is for prime_clone to recover from errors, HTTP errors are only optionally printed to screen and never cause death in this

Re: [RFC 0/3] http: avoid repeatedly adding curl easy to curlm

On Tue, 13 Sep 2016, Eric Wong wrote: > What is unclear to me is how only Yaroslav's repository seems to > trigger this bug after all these years... Thank you Eric very much for tracking down this issue! Since issue is intermittent, I guess people just didn't bother going through reporting if

Re: [RFC 0/3] http: avoid repeatedly adding curl easy to curlm

Eric Wong <e...@80x24.org> writes: > The key patch here is 3/3 which seems like an obvious fix to > adding the problem of adding a curl easy handle to a curl multi > handle repeatedly. Yeah, sounds like the right thing to do and 2/3 makes it really easy to read the resul

[RFC 3/3] http: always remove curl easy from curlm session on release

We must call curl_multi_remove_handle when releasing the slot to prevent subsequent calls to curl_multi_add_handle from failing with CURLM_ADDED_ALREADY (in curl 7.32.1+; older versions returned CURLM_BAD_EASY_HANDLE) Signed-off-by: Eric Wong <e...@80x24.org> --- http.c | 10 ++

[RFC 0/3] http: avoid repeatedly adding curl easy to curlm

(I have some hours online today, so I decided to work on this) The key patch here is 3/3 which seems like an obvious fix to adding the problem of adding a curl easy handle to a curl multi handle repeatedly. What is unclear to me is how only Yaroslav's repository seems to trigger this bug after

[PATCH] imap-send: Tell cURL to use imap:// or imaps://

Right now the imap:// or imaps:// part of imap.host is not being passed on to cURL. Perhaps it was able to guess correctly under some circumstances, but I was not able to find one; it was just trying to make HTTP requests for me. It’s better to be explicit in any case. Signed-off-by: Anders

[PATCH/RFC 7/7] remote-curl: add sparse prefix

Signed-off-by: Robin Ruede --- remote-curl.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/remote-curl.c b/remote-curl.c index e181e62..b9f7cf1 100644 --- a/remote-curl.c +++ b/remote-curl.c @@ -20,6 +20,7 @@ static struct strbuf url =

Re: [PATCH] ./configure.ac: Detect SSL in libcurl using curl-config

Дилян Палаузов <git-...@aegee.org> writes: > The API of libcurl does not mention Curl_ssl_init() and when curl is built > with -flto, the Curl_ssl_init symbol is not exported. > > https://curl.haxx.se/libcurl/using/ suggests calling > curl-config --feature | grep SSL >

[PATCH] ./configure.ac: Detect SSL in libcurl using curl-config

The API of libcurl does not mention Curl_ssl_init() and when curl is built with -flto, the Curl_ssl_init symbol is not exported. https://curl.haxx.se/libcurl/using/ suggests calling curl-config --feature | grep SSL to see, if the installed curl has SSL support. Another approach would

[PATCH 04/10] Extending internal CURL wrapper for POST upload

http.h| 17 +++-- remote-curl.c | 2 +- 3 files changed, 39 insertions(+), 10 deletions(-) diff --git a/http.c b/http.c index 69da445..a108658 100644 --- a/http.c +++ b/http.c @@ -1373,17 +1373,19 @@ static void http_opt_request_remainder(CURL *curl, off_t pos) static int

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

Hi, guys! > I sent in a patch (and I believe I CC'd you) that adds an option > http.emptyAuth that can be used in this case. It should make its way to > a future release. Somehow I've missed your letter... > The patch has been queued as 121061f6 (http: add option to try > authentication

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

Dmitry Vilkov writes: > Hi guys! Any luck with fixing this issue? I think Brian suggested an alternative approach, to which you earler responded >> That would be great! Definitely it will be much better solution than >> patch I've proposed. The patch has been queued

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

On Sat, Feb 20, 2016 at 05:35:19PM +0300, Dmitry Vilkov wrote: > Maybe you could accept my patch, so users would use > "credential.helper=store" to avoid using ":@" in remote URL? At least > for now, while there is no good solution to this issue? It would be > very helpful because now we have to

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

Hi guys! Any luck with fixing this issue? I would like to draw your attention to the fact that Git starting from version 2.3.1 is unusable with servers that support GSS-Negotiation (e.g. Microsoft TFS). Sorry, english is not my native language and probably I was not clear enough when described

Re: [PATCH] remote-curl: Include curl_errorstr on SSL setup failures

On Sat, Feb 13, 2016 at 05:39:34PM -0800, Shawn Pearce wrote: > For curl error 35 (CURLE_SSL_CONNECT_ERROR) users need the > additional text stored in CURLOPT_ERRORBUFFER to debug why > the connection did not start. This is curl_errorstr inside > of http.c, so include that in

Re: [PATCH] remote-curl: Include curl_errorstr on SSL setup failures

On Sun, Feb 14, 2016 at 8:50 AM, Jeff King <p...@peff.net> wrote: > On Sat, Feb 13, 2016 at 05:39:34PM -0800, Shawn Pearce wrote: > >> For curl error 35 (CURLE_SSL_CONNECT_ERROR) users need the >> additional text stored in CURLOPT_ERRORBUFFER to debug why >>

[PATCH] remote-curl: Include curl_errorstr on SSL setup failures

For curl error 35 (CURLE_SSL_CONNECT_ERROR) users need the additional text stored in CURLOPT_ERRORBUFFER to debug why the connection did not start. This is curl_errorstr inside of http.c, so include that in the message if it is non-empty. Sometimes HTTP response codes aren't yet available

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

2016-02-06 0:52 GMT+03:00 Junio C Hamano : > "brian m. carlson" writes: > >> 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

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

On Fri, 5 Feb 2016, Junio C Hamano wrote: OK, as Brian said, that use case would need to be in the log message, at least. I am curious, though, if you can give just a random string to username, or at least that must match what the underlying authentication mechanism uses. Brian, I can see

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 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

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

Dmitry Vilkov writes: > 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

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

On Fri, Feb 05, 2016 at 09:54:50AM -0800, Junio C Hamano wrote: > OK, as Brian said, that use case would need to be in the log > message, at least. I am curious, though, if you can give just a > random string to username, or at least that must match what the > underlying authentication mechanism

<    1   2   3   4   5   >