Re: [PATCH v6] http.postbuffer: allow full range of ssize_t values

On Tue, Apr 11, 2017 at 07:39:27PM -0700, Junio C Hamano wrote: > Jeff King writes: > > >> The only unresolved issue was whether we can count on curl being new > >> enough for CURLOPT_POSTFIELDSIZE_LARGE to be present. I say > >> "unresolved" but it is resolved in my mind since

Re: [PATCH v6] http.postbuffer: allow full range of ssize_t values

Jeff King writes: >> The only unresolved issue was whether we can count on curl being new >> enough for CURLOPT_POSTFIELDSIZE_LARGE to be present. I say >> "unresolved" but it is resolved in my mind since git doesn't build and >> pass tests with such old versions of curl ---

Re: [PATCH v6] http.postbuffer: allow full range of ssize_t values

On Tue, Apr 11, 2017 at 11:27:40AM -0700, Jonathan Nieder wrote: > David Turner wrote: > > > Unfortunately, in order to push some large repos where a server does > > not support chunked encoding, the http postbuffer must sometimes > > exceed two gigabytes. On a 64-bit system, this is OK: we

Re: [PATCH v6] http.postbuffer: allow full range of ssize_t values

David Turner wrote: > Unfortunately, in order to push some large repos where a server does > not support chunked encoding, the http postbuffer must sometimes > exceed two gigabytes. On a 64-bit system, this is OK: we just malloc > a larger buffer. > > This means that we need to use

[PATCH v6] http.postbuffer: allow full range of ssize_t values

Unfortunately, in order to push some large repos where a server does not support chunked encoding, the http postbuffer must sometimes exceed two gigabytes. On a 64-bit system, this is OK: we just malloc a larger buffer. This means that we need to use CURLOPT_POSTFIELDSIZE_LARGE to set the buffer