Re: Proposal/Discussion: Turning parts of Git into libraries

From: Taylor Blau <me@ttaylorr.com>
Date: Feb 21, 2023, 19:09 UTC
Message-ID: <Y/UXBw3Y9YnXUBIN@nand.local>
In-Reply-To: <CAJoAoZ=Cig_kLocxKGax31sU7Xe4==BGzC__Bg2_pr7krNq6MA@mail.gmail.com>

On Fri, Feb 17, 2023 at 01:12:23PM -0800, Emily Shaffer wrote:

Show 9 quoted lines

> This turned out pretty long-winded, so a quick summary before I dive in:
>
> - We want to compile parts of Git as independent libraries
> - We want to do it by making incremental code quality improvements to Git
> - Let's avoid promising stability of the interfaces of those libraries
> - We think it'll let Git do cool stuff like unit tests and allowing
>   purpose-built plugins
> - Hopefully by example we can convince the rest of the project to join
>   in the effort

Like others, I am less interested in the VFS-specific components you mention here, but I suspect that is just one particular instance of something that would be benefited by making git internals exposed via a linkable library.

I don't have objections to things like reducing our usage of globals, making fewer internal functions die() when they encounter an error, and so on. But like Junio, I suspect that this is definitely an instance of a "devil's in the details" kind of problem.

That's definitely my main concern: that this turns out to be much more complicated than imagined and that we leave the codebase in a worse state without much to show. A lesser version of that outcome would be that we cause a lot of churn in the tree with not much to show either.

So I think we'd want to see some more concrete examples with clear benefits to gauge whether this is a worthwhile direction. I think that strbuf.h is too trivial an example to demonstrate anything useful. Being able to extract config.h into its own library so that another non-Git program could link against it and implement 'git config'-like functionality would be much more interesting.

Thanks, Taylor