Re: Building Git with HTTPS support: avoiding libcurl?

[Daniel Stenberg <daniel@haxx.se>]

On Tue, 22 Dec 2015, Paul Smith wrote:

> I grok that Git doesn't want to re-invent the wheel and that libcurl is 
> convenient.  I just wonder if anyone knows of another wheel, that doesn't 
> come attached to an entire tractor-trailer, that could be used instead :).

But if you would consider another lib, then you could just rebuild your own 
libcurl instead from source, entirely without any dependencies on other libs! 
That would be similar to finding another lib with less dependencies. (As 
already mentioned, you'd still need crypto and TLS support no doubt.)

That huge dependency collection is there much because your distro decided that 
having a libcurl with all that support is preferable. libcurl itself offers 
lots of customizability at build-time so you can strip out most of that if you 
wanted to.

But why do the distros build and provide a libcurl that can do all this?

I think you can look at this from a slightly higher altitude. By re-using a 
very widely used, well developed and properly documented library (yeah, I 
claim it is but you don't need to take my word for it) that is available 
everywhere - git benefits. By having many projects use the same lib, even if 
no two projects use the exact same feature set, we get more reliable software 
in the entire ecosystem - with less work.

I would guess that switching out libcurl in git would be a not insignificant 
amount of work, as no libcurl alternative I'm aware of is even close to this 
API.

-- 

  / daniel.haxx.se