On Wed, Aug 09, 2017 at 11:42:12PM +0200, Johannes Schindelin wrote: > > This is a resurrection of the thread from April: > > > > https://public-inbox.org/git/20170404025438.bgxz5sfmrawqswcj@xxxxxxxxxxxxxxxxxxxxx/ > > 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 CentOS, > and I really needed to install Git on it. > > In such a case, it is often preferable to be able to build against an old > cURL -- even if some of the fancier features might be broken, and even if > some minor compile errors need to be fixed. > > I know I was happy to compile Git against an ancient cURL back then. > > Just so you understand where I come from when I would like to caution > against dropping support for older cURL unless it *really* adds an > *enormous* amount of maintenance burden. > > I mean, if we even go out of our way to support the completely outdated > and obsolete .git/branches/ for what is likely a single user, it may not > be the worst to keep those couple of #ifdef guards to keep at least > nominal support for older cURLs? You've totally ignored the argument I made back then[1], and which I reiterated in this thread. So I'll say it one more time: the more compelling reason is not the #ifdefs, but the fact that the older versions are totally untested. In fact, they do not even compile, and yet I have not seen any patches to fix that. So IMHO this is about being honest with users about which versions we _actually_ support. -Peff [1] https://public-inbox.org/git/20170410182215.figy7hm4sogwipyz@xxxxxxxxxxxxxxxxxxxxx/
