On Sun, Aug 06, 2017 at 06:34:22PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > That is fine by me. AFAIK, we already build the curl support by default > > when a sufficiently-advanced version of curl is available. So if there > > were feature-parity problems hopefully somebody would have reported it. > > > > I think the deprecation here can be relatively fast because we're not > > actually dropping support for any feature. We're just requiring that > > they install curl to get the same functionality (which might be > > inconvenient, but it's a heck of a lot less inconvenient than "there's > > no way to do what you want anymore"). > > Yeah, as long as imap-supporting libcurl is not too recent and are > available everywhere, we should be OK. I think we're not quite ready to switch to curl based on comments in the nearby thread. But just for reference, since I started looking into this... The defines in the Makefile turn on USE_CURL_FOR_IMAP_SEND want curl 7.34.0. That's only from 2013, which is probably recent enough that it may cause a problem (I had originally thought it was a few years older, but I forgot the curl version hex encoding; 072200 is 7.34.0). For comparison, nothing older than curl 7.19.4 will work for building Git since v2.12.0, as we added some unconditional uses of CURLPROTO_* there. Nobody seems to have noticed or complained. I pointed this out a few months ago[1] and suggested we clean up some of the more antiquated #if blocks in http.c that don't even build. There was some complaint that we should keep even these ancient versions working, but the compile error is still in "master". So it's not clear to me that anybody cares about going that far back (which is mid-2009), but I'd guess that 2013 might cause some problems. [1] https://public-inbox.org/git/20170404025438.bgxz5sfmrawqswcj@xxxxxxxxxxxxxxxxxxxxx/ if you're curious (you were offline for a while at that time, I think).
