Re: Reducing git size by building libgit.so

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 12, 2019, 09:41 UTC
Message-ID: <87y32787k9.fsf@evledraar.gmail.com>
In-Reply-To: <21f1f334-755e-3283-d0da-ec0ab9231cfc@ucdenver.edu>

On Tue, Jun 11 2019, Elmar Pruesse wrote:

Show 10 quoted lines

> Hi!
>
> The total compiled size of libexec/git-core is currently somewhere
> around 30 MB. This is largely due to a number of binaries linking
> statically against libgit.a. For some folks, every byte counts. I
> meddled with the Makefile briefly to make it build and use a libgit.so
> instead, which dropped package size down to 5MB.
>
> Are there, beyond the ~20 ms in extra startup time and the slightly
> bigger hassle with DSO locations, reasons for the choice to link statically?

brian mentioned API stability. I'd be fine with having a *.so shipped with git. We'd document the API non-stability, and of course it's GPL so you can only link other GPL programs to it, but if people would be fine with still using it and very closely following git development as we break their API/ABI why not.

Have you looked at INSTALL_SYMLINKS & friends? I.e. maybe you're measuring size without accounting for most of the binaries being hardlinks to the same thing.

We still have some stand-alone binaries, but IIRC there's under 5 of those with INSTALL_SYMLINKS. We could probably also just make those built-ins to get the rest of the size benefits.

I.e. we'd just have one git binary, everything else symlinking to that, and we'd route to the right program by inspecting argv, which we mostly do already.