On Tue, Feb 21, 2023 at 11:10 AM Taylor Blau <me@xxxxxxxxxxxx> wrote: > > On Fri, Feb 17, 2023 at 01:12:23PM -0800, Emily Shaffer wrote: > > 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. Yeah, I'm really hoping we don't end up with ugly half-changes too. Some examples of "partial credit" that I'd be happy with: - Fewer internal libraries relying on globals like the_repository/the_index/etc (we've already started this effort, libification or no) - An "ugly" library interface becoming clearer and easier to use (and internal callers updated) - Figuring out an "error reporting type" that works well for us There are some things that *are* ugly, for example, calling a library via a vtable. But I do feel comfortable waiting to introduce that kind of thing until we really need it, at which point I suspect we'll have already made some successful strides with libification in general. It's not so great to just trust me to say "I promise not to make ugly changes" - I'd appreciate the community's help pushing back if we propose doing something in an untidy way without clear justification. > A lesser version of that outcome would be > that we cause a lot of churn in the tree with not much to show either. I'm actually not so concerned about this! The "churn", as I see it, comes in the form of code cleanup that already makes Git more understandable for Git hackers. We do spend some time on that now, as a project, but I wouldn't be unhappy if we spent even more :) > > 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. Sure - I'm also looking forward to seeing it. Thanks for your thoughtful reply. - Emily
