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 CURLOPT_POSTFIELDSIZE_LARGE? 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. > > -Peff