Re: [PATCH v6] http.postbuffer: allow full range of ssize_t values
- Date: Tue, 11 Apr 2017 19:39:27 -0700
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: [PATCH v6] http.postbuffer: allow full range of ssize_t values
Jeff King <peff@xxxxxxxx> 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 --- what's unresolved is
>> formalizing what the oldest curl version is that we want to support.
>> And that doesn't need to hold this patch hostage.
> It could build on older curl with a minor fix; the regression is in
> v2.12. So if we did want to continue to support the same versions of
> curl we did in v2.11, we could apply that fix and then we _would_ care
> about #ifdef-ing this.
What would the fix be? Have a code that notices that the value set
to http.postbuffer is too large and ignore the request on the other
side of #ifdef, i.e. when Git is built with older curl that lack
Something like that may be prudent for the 'maint' track. But I
tend to agree that for feature releases, we should revisit what the
oldest version we claim to support from time to time and raise the
floor when we notice nobody has even been attempting to build the
other side of the #ifdef (and during that exercise, those who do
want to have older versions supported _can_ argue against removal of
#ifdef with patch to keep both side of #ifdef working). I fully
agree with what you said earlier that it is irresponsible to the
users to keep #ifdef that gives a false impression that we are
maintaining both sides of them, when in reality the older side has
bit-rotten without anybody even noticing.
I suspect that it is a bit too late for the next release, but we can
decide by mid May for the one after 2.13 if we waned to.
> That isn't my preferred route; just pointing out that if the "oldest
> curl" question isn't settled, that could still be relevant to this
> patch. It doesn't have to be held hostage to the fix, but we should be
> aware we are digging the hole deeper.