like
> Date: Fri, 13 Jun 2014 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
014 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 <
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 great
.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
nteresting 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". Or "even
the antique people are giving up el4, and it might be reasonable to
start requiring curl >= 7.11.0".
I do not k
op of 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
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 m
tioned yet.
Your story shows 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
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.
Brandon Williams writes:
> Teach remote-curl to understand push options and to be able to convey
> them across HTTP.
>
> Signed-off-by: Brandon Williams
> ---
An earlier 438fc684 ("push options: pass push options to the
transport helper", 2017-02-08) said:
...
On 03/22, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > Teach remote-curl to understand push options and to be able to convey
> > them across HTTP.
> >
> > Signed-off-by: Brandon Williams
> > ---
>
> An earlier 438fc684 ("push optio
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 pu
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 *pref
Teach remote-curl to understand push options and to be able to convey
them across HTTP.
Signed-off-by: Brandon Williams
---
Documentation/git-send-pack.txt | 6 ++
builtin/send-pack.c | 5 +
remote-curl.c | 8
t/t5545-push-options.sh
Signed-off-by: Nicolas Morey-Chaisemartin
---
imap-send.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 90b8683ed..4ebc16437 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -35,13 +35,7 @@ typedef void *SSL;
#include "http.h"
#endif
-#if defined(USE_CU
Now that curl is enable by default, use the curl implementation
for imap too.
The goal is to validate feature parity between the legacy and
the curl implementation, deprecate thee legacy implementation
later on and in the long term, hopefully drop it altogether.
Signed-off-by: Nicolas Morey
Recent versions of Git will not build with curl older than
7.11.1 due to (at least) two issues:
- our use of CURLOPT_POSTFIELDSIZE in 37ee680d9b
(http.postbuffer: allow full range of ssize_t values,
2017-04-11). This field was introduced in curl 7.11.1.
- our use of CURLPROTO_
As discussed in the previous commit, Git is not well-tested
with old versions of curl (and in fact since v2.12.0 does
not even compile with versions older than 7.19.4). Let's
stop pretending we support curl that old and drop any
now-obslete #ifdefs.
Choosing 7.16.0 is a somewhat arbitrary c
Since v2.12.0, Git does not compile with versions of curl
older than 7.19.4. That version of curl is about 8 years
old. This means it may still be used in some distributions
with long-running support periods. But the fact that we
haven't received a single bug report about the compile-time
bre
We already fail to build with versions of curl older than
7.19.4. But doing an explicit check with an #error has two
benefits.
One is that it makes it clear to users that the build
failure is intentional, so they don't waste time trying to
debug it.
And two is that it documents our current
Hi Peff,
On Wed, 9 Aug 2017, Jeff King wrote:
> This is a resurrection of the thread from April:
>
>
> https://public-inbox.org/git/20170404025438.bgxz5sfmrawqs...@sigill.intra.peff.net/
As before, I would like to point out that people running with older cURL
are most likely no
that people running with older cURL
> are most likely not at liberty to change the system libraries.
>
> I know that I didn't when I was working on a very expensive microscope
> whose only certified control computer ran a very old version of CentOS,
> and I really needed to i
As before, I would like to point out that people running with older cURL
> are most likely not at liberty to change the system libraries.
>
> I know that I didn't when I was working on a very expensive microscope
> whose only certified control computer ran a very old version of
awqs...@sigill.intra.peff.net/
> >
> > As before, I would like to point out that people running with older cURL
> > are most likely not at liberty to change the system libraries.
> >
> > I know that I didn't when I was working on a very expensive microscope
> >
currently have 2.13.3 up for el4, el5, el6 and el7.
Only el4 requires any patches, the rest will build out of the box with
the vendor supplied version of curl.
The plan was to drop the el4 builds for 2.14.0 to get rid of the patches.
In fact, they do not even compile, and
yet I have not seen any
the vendor supplied version of curl.
The plan was to drop the el4 builds for 2.14.0 to get rid of the patches.
In fact, they do not even compile, and
yet I have not seen any patches to fix that.
I just built a pristine 2.14.0 on CentOS 5 with curl 7.15.5. No problems
at all neither with buildin
you sent at the
time, but I didn't see one for the CURLPROTO issue. And indeed, it is
still broken for me:
$ cd /path/to/curl/repo
$ git checkout curl-7_15_5
$ ./buildconf && ./configure --prefix=/tmp/foo && make install
$ cd /path/to/git
$ git checkout v2.14.0
$ make C
On Thu, Aug 10, 2017 at 11:36:41AM +0200, Johannes Schindelin wrote:
> Hopefully I had better luck expressing my concerns this time?
I understand your argument much better now. I'm still not sure I agree.
-Peff
re are a dozen #ifdefs and I don't know whether
they still work. I don't know whether anybody (who most likely has
better things to do than read the Git mailing list) is still using
those. So let's just remove them." was why you were suggesting to
clean up the (apparent) suppor
ut I didn't see one for the CURLPROTO issue. And indeed, it is
still broken for me:
$ cd /path/to/curl/repo
$ git checkout curl-7_15_5
$ ./buildconf && ./configure --prefix=/tmp/foo && make install
$ cd /path/to/git
$ git checkout v2.14.0
$ make CURLDIR=/tm
On Fri, Aug 11, 2017 at 12:23:42AM +0200, Tom G. Christensen wrote:
> > > I just built a pristine 2.14.0 on CentOS 5 with curl 7.15.5. No problems
> > > at
> > > all neither with building nor with running the testsuite.
> >
> > As you can see, this d
mailing list) is still using
> those. So let's just remove them." was why you were suggesting to
> clean up the (apparent) support of older curl in the code, though.
>
> Isn't the reason why your series simplifies these #ifdefs away
> because we by accident started usi
could certainly see it being
dropped after the compilation, but I'm surprised that it wouldn't
complain about the undeclared identifiers in the first place.
You're right, that should not be able to handle it.
Can you please double-check that you're
building against the correct vers
On Fri, Aug 11, 2017 at 01:17:51AM +0200, Tom G. Christensen wrote:
> > OK, thanks for double-checking. I'm still puzzled why your build
> > succeeds and mine does not.
>
> I know what's going on now and it's so simple.
> Red Hats version of curl 7.15.5 includ
On 11/08/17 01:23, Jeff King wrote:
On Fri, Aug 11, 2017 at 01:17:51AM +0200, Tom G. Christensen wrote:
OK, thanks for double-checking. I'm still puzzled why your build
succeeds and mine does not.
I know what's going on now and it's so simple.
Red Hats version of curl 7.
ers
> about what to expect[1].
As usual, I forgot all my footnotes.
[1] When I've talked about keeping expectations reasonable, I'm a lot
less interested in "oops, I built Git and this particular feature
didn't work". It's easy to write that off as "w
The curl packages provided by Red Hat for RHEL contain several
backports of features from later curl releases.
This causes problems with current version based checks in http.c.
Here is an overview of the features that have been backported:
7.10.6 (el3) Backports CURLPROTO_*
7.12.1 (el4) Backports
Hi Paolo,
On Thu, 10 Aug 2017, Paolo Ciarrocchi wrote:
> Il 10 ago 2017 11:39 AM, "Johannes Schindelin"
> ha scritto:
>
>
>
> Footnote *1*: It is no secret that I find our patch submission less than
> inviting. Granted, *I* use it. *I* did not have problems entering the
> mailing list. But th
Ping.
I'd like to get feedback from Windows developer on patch #2
Patch#3 will probably need some updates as I expected Jeff old curl drop
patches to make it in.
As it seems to be going another way a few more ifdefs will be required
Nicolas
Le 09/08/2017 à 16:43, Nicolas Morey-Chaisemar
On Tue, Aug 15, 2017 at 10:49 AM, Nicolas Morey-Chaisemartin
wrote:
> Ping.
>
> I'd like to get feedback from Windows developer on patch #2
> Patch#3 will probably need some updates as I expected Jeff old curl drop
> patches to make it in.
> As it seems to be going anothe
er we could come up with a suitable
replacement. And that would depend on how libcurl works on Windows, I
think (because it's going to feed whatever we give it to other syscall
wrappers).
> - should socketpair always be used or limited to the curl over tunnel case ?
> I don't think
On Tue, Aug 15, 2017 at 07:46:11PM +0200, Nicolas Morey-Chaisemartin wrote:
> Patch#3 will probably need some updates as I expected Jeff old curl drop
> patches to make it in.
> As it seems to be going another way a few more ifdefs will be required
I'm not sure where we're
Hi,
On Tue, 15 Aug 2017, Stefan Beller wrote:
> On Tue, Aug 15, 2017 at 10:49 AM, Nicolas Morey-Chaisemartin
> wrote:
> > Ping.
> >
> > I'd like to get feedback from Windows developer on patch #2
> > Patch#3 will probably need some updates as I expected Jeff
(Sent a reply from my phone while out of town but couldn't find it so here it
is again)
It's available on my github:
https://github.com/nmorey/git/tree/dev/curl-tunnel
The series had been stlighly changed since the patch were posted, mostly to add
the proper ifdefs to handle
red.
I'm not sure there is a portable "anonymous socket" API out there that'll
work...
>> - should socketpair always be used or limited to the curl over tunnel case ?
>> I don't think there is too much different between an unname pipe and a
>> socketpa
Am 21.08.2017 um 09:27 schrieb Nicolas Morey-Chaisemartin:
(Sent a reply from my phone while out of town but couldn't find it so here it
is again)
It's available on my github:
https://github.com/nmorey/git/tree/dev/curl-tunnel
The series had been stlighly changed since the patch w
dn't find it so here
>> it is again)
>>
>> It's available on my github:
>> https://github.com/nmorey/git/tree/dev/curl-tunnel
>>
>> The series had been stlighly changed since the patch were posted, mostly to
>> add the proper ifdefs to handle o
On Mon, Aug 21, 2017 at 09:34:19AM +0200, Nicolas Morey-Chaisemartin wrote:
> >> It appears curl do not support the PREAUTH tag.
> > Too bad. IMHO preauth is the main reason to use a tunnel in the first
> > place.
>
> It shouldn't be too hard to add support for
Hi Hannes,
On Tue, 22 Aug 2017, Johannes Sixt wrote:
> Am 21.08.2017 um 09:27 schrieb Nicolas Morey-Chaisemartin:
> > (Sent a reply from my phone while out of town but couldn't find it so here
> > it is again)
> >
> > It's available on my github:
> >
On Thu, Aug 24, 2017 at 10:00:47AM +0200, Nicolas Morey-Chaisemartin wrote:
> > Yes, I agree. I was hoping when we started this discussion that we were
> > more ready to switch to curl-by-default. But sadly, that isn't close to
> > being the case. But hopefully we can at
On Thu, 24 Aug 2017, Jeff King wrote:
I opened a bug upstream and they already fixed this.
https://github.com/curl/curl/pull/1820
Cool! That's much faster than I had expected. :)
Your wish is our command! =)
--
/ daniel.haxx.se (who landed the IMAP PREAUTH fix in curl)
Le 24/08/2017 à 15:53, Jeff King a écrit :
> On Thu, Aug 24, 2017 at 10:00:47AM +0200, Nicolas Morey-Chaisemartin wrote:
>
>>> Yes, I agree. I was hoping when we started this discussion that we were
>>> more ready to switch to curl-by-default. But sadly, that isn'
On Thu, Aug 24, 2017 at 04:15:04PM +0200, Nicolas Morey-Chaisemartin wrote:
> >> 1) There does not seem to be an easy/clean workaround for the lack of
> >> socketpair on windows.
> >> Fidling with a loopback AF_UNIX?AF_LOCAL socket should work but it
> >> means creating a socket file somewhere wh
On Thu, Aug 24, 2017 at 04:02:19PM +0200, Daniel Stenberg wrote:
> On Thu, 24 Aug 2017, Jeff King wrote:
>
> > > I opened a bug upstream and they already fixed this.
> > > https://github.com/curl/curl/pull/1820
> >
> > Cool! That's much faster than
On Thu, 24 Aug 2017, Jeff King wrote:
Oh good. While I have you here, have you given any thought to a curl handle
that has two half-duplex file descriptors, rather than a single full-duplex
socket? That would let us tunnel over pipes rather than worrying about the
portability of socketpair
Hi,
Again SIGPIPE is seen with curl version 7.45.0 with multi interface.
Backtrace shows :
#7 0x7f141bea40cd in Curl_ossl_close (conn=0x7f14193f9848, sockindex=0)
at vtls/openssl.c:881
#8 0x7f141bea8f54 in Curl_ssl_close (conn=0x7f14193f9848, sockindex=0)
at vtls/vtls.c:527
#9
On Tue, 22 May 2018, curlUser wrote:
Again SIGPIPE is seen with curl version 7.45.0 with multi interface.
Backtrace shows :
...
Looks like SIGPIPE_IGNORE to be added in prune_dead connections or in
disconnect_if_dead? Can anyone comment on this.
I'm pretty sure this issue isn't
We may not be able to upgrade to 7.60.0 any soon,
Is the fix present in 7.45 , in this sequence of code.
Please let me know.
--
Sent from: http://git.661346.n2.nabble.com/
sn't exist anymore. libcurl 7.45.0 is 2.5 years and
1500+ bug fixes old after all. My casual searches for a curl problem like this
- fixed in 7.45.0 or later - also failed.
--
/ daniel.haxx.se
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 = STRBUF_INIT;
struct op
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 so
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
be
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 this
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,
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
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
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
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
co
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
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
'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
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
After making initial contact with an http server, we have to decide if
the server supports smart-http, and if so, which version. Our rules are
a bit inconsistent:
1. For v0, we require that the content-type indicates a smart-http
response. We also require the response to look vaguely like a
I have curl 7.35.0 installed on my ubuntu14.04, version infos is as below
I have recompiled git against openssl. the git version is 1.9.1. I
encountered this error "error: git-remote-http died of signal 13" when I
issue `git clone http://github.com/tensorflow/tensorflow.git`. Should
On Wed, Aug 8, 2018 at 4:52 AM Johannes Schindelin via GitGitGadget
wrote:
>
> We should not interrupt. sentences in the middle.
I love this. commit message. :-)
...
> /* The client backend isn't giving us compressed data so
> -* we can try to deflate it ourselve
James Knight writes:
> Makefile | 21 +++--
> config.mak.uname | 5 ++---
> configure.ac | 17 +++--
> 3 files changed, 16 insertions(+), 27 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index b08d5ea25..c3be87b0e 100644
> --- a/Makefile
> +++ b/Mak
Adjusting the build process to rely more on curl-config to populate
linker flags instead of manually populating flags based off detected
features.
Originally, a configure-invoked build would check for SSL-support in the
target curl library. If enabled, NEEDS_SSL_WITH_CURL would be set and
used in
On Mon, Nov 12, 2018 at 2:45 PM wrote:
>
> When a smart HTTP server sends an error message via pkt-line,
> remote-curl will fail to detect the error (which usually results in
> incorrectly falling back to dumb-HTTP mode).
>
> This patch adds a check in discover_refs() for
stead...@google.com writes:
> When a smart HTTP server sends an error message via pkt-line,
> remote-curl will fail to detect the error (which usually results in
> incorrectly falling back to dumb-HTTP mode).
>
> This patch adds a check in discover_refs() for server-side error
>
stead...@google.com writes:
> When a smart HTTP server sends an error message via pkt-line,
> remote-curl will fail to detect the error (which usually results in
> incorrectly falling back to dumb-HTTP mode).
>
> This patch adds a check in discover_refs() for server-side error
>
On Mon, Nov 12, 2018 at 02:44:56PM -0800, stead...@google.com wrote:
> When a smart HTTP server sends an error message via pkt-line,
> remote-curl will fail to detect the error (which usually results in
> incorrectly falling back to dumb-HTTP mode).
>
> This patch adds a check i
stead...@google.com writes:
> When a smart HTTP server sends an error message via pkt-line,
> remote-curl will fail to detect the error (which usually results in
> incorrectly falling back to dumb-HTTP mode).
OK, that is a valid thing to worry about.
>
> This patch adds a check i
On 2018.11.13 12:02, Junio C Hamano wrote:
> stead...@google.com writes:
>
> > When a smart HTTP server sends an error message via pkt-line,
> > remote-curl will fail to detect the error (which usually results in
> > incorrectly falling back to dumb-HTTP mode).
> >
On 2018.11.13 09:26, Jeff King wrote:
> On Mon, Nov 12, 2018 at 02:44:56PM -0800, stead...@google.com wrote:
>
> > When a smart HTTP server sends an error message via pkt-line,
> > remote-curl will fail to detect the error (which usually results in
> > incorrectly fallin
On 2018.11.13 23:30, Junio C Hamano wrote:
> stead...@google.com writes:
>
> > When a smart HTTP server sends an error message via pkt-line,
> > remote-curl will fail to detect the error (which usually results in
> > incorrectly falling back to dumb-HTTP mode).
>
>
On Tue, Nov 13, 2018 at 02:25:40PM -0800, Josh Steadmon wrote:
> > The magic "4" here and in the existing "version 2" check is because we
> > are expecting pkt-lines. The original conditional always calls
> > packed_read_line_buf() and will complain if we didn't actually get a
> > pkt-line.
> >
>
On Tue, Nov 13, 2018 at 07:49:15PM -0500, Jeff King wrote:
> Yes, the packet_read_line_buf() interface will both advance the buf
> pointer and decrement the length. So if we want to "peek", we have to
> do so with a copy (there's a peek function if you use the packet_reader
> interface, but that
On 2018.11.14 02:00, Jeff King wrote:
> On Tue, Nov 13, 2018 at 07:49:15PM -0500, Jeff King wrote:
>
> > Yes, the packet_read_line_buf() interface will both advance the buf
> > pointer and decrement the length. So if we want to "peek", we have to
> > do so with a copy (there's a peek function if
claiming "text/html" (and after my patch, we
correctly fall back to dumb-http).
> If no one has any objections, I'll include the diff below in v2. Thanks
> for the help Jeff!
I think it makes sense to do the refactoring first as a separate step.
And of course it needs a comm
After making initial contact with an http server, we have to decide if
the server supports smart-http, and if so, which version. Our rules are
a bit inconsistent:
1. For v0, we require that the content-type indicates a smart-http
response. We also require the response to look vaguely like a
Change one hard-coded use of the constant 40 to a reference to
the_hash_algo. In addition, switch a use of get_oid_hex to
parse_oid_hex to avoid the need to use a constant.
Signed-off-by: brian m. carlson
---
remote-curl.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff
The stdin_preamble field in struct rpc_state is only used in
rpc_service(), and not in any functions it directly or indirectly calls.
Refactor it to become an argument of rpc_service() instead.
An observation of all callers of rpc_service() shows that the preamble
is always set, so we no longer ne
The result field in struct rpc_state is only used in rpc_service(), and
not in any functions it directly or indirectly calls. Refactor it to
become an argument of rpc_service() instead.
Signed-off-by: Jonathan Tan
---
remote-curl.c | 25 +
1 file changed, 13 insertions(+)
The argv field in struct rpc_state is only used in rpc_service(), and
not in any functions it directly or indirectly calls. Refactor it to
become an argument of rpc_service() instead.
Signed-off-by: Jonathan Tan
---
remote-curl.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
mmit was merged in 2.20.0:
>
> * The way -lcurl library gets linked has been simplified by taking
> advantage of the fact that we can just ask curl-config command how.
>
> Unfortunately it assumes that curl-config is in the path which is not
> always the case. When using "--wi
Paul Gortmaker writes:
> Currently, if you don't have curl installed, you will get
>
> $ make distclean 2>&1 | grep curl
> /bin/sh: curl-config: not found
> /bin/sh: curl-config: not found
> /bin/sh: curl-config: not found
> /bin/sh: curl-conf
"Joachim Schmitz" writes:
> Signed-off-by: Joachim Schmitz
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 ++
> 1 file
> 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" writes:
>
> >
"Joachim Schmitz" 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
> ---
Perfect ;-)
> http.c |
101 - 200 of 577 matches
Mail list logo
