On Tue, Apr 4, 2017 at 4:54 AM, Jeff King <p...@peff.net> wrote: > My feeling is that this is old enough to stop 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 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? :) > > If we declared 7.16.0 as a cutoff, we could unconditionally define > USE_CURL_MULTI, which gets rid of quite a few messy ifdefs.
I don't object to this patch, but just as a general comment, in enterprise-y environments using an old OS (e.g. CentOS 5/6) & then compiling some selected packages like git based on OS libraries is quite common. E.g. at work we're running git 2.12.0 compiled against CentOS 6 libraries, which has curl 7.20.1, released on Apr 14 2010. Not so long ago we were still running CentOS 5 which comes with 7.15.5 released in Aug 7 2006 which would break with your patch. Whether we support that is another question, I think it's reasonable to say that if you're compiling git on such an old system you also need to compile a libcurl instead of using the OS version. I just wanted to point out that this *does* happen, someone is going to be compiling new git releases on CentOS 5 & will be hit by this.
