Re: [PATCH 0/4] dropping support for older curl
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Aug 9, 2017, 21:42 UTC
- Message-ID
- <alpine.DEB.2.21.1.1708092337350.11175@virtualbox>
- In-Reply-To
- <20170809120024.7phdjzjv54uv5dpz@sigill.intra.peff.net>
Hi Peff,
On Wed, 9 Aug 2017, Jeff King wrote:
> This is a resurrection of the thread from April: > > https://public-inbox.org/git/20170404025438.bgxz5sfmrawqswcj@sigill.intra.peff.net/
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?
Ciao, Dscho