On 2024-01-10 at 22:11:34, Junio C Hamano wrote:

A few obvious ones that come to my mind are that you should be able
to write a new merge strategy and link the resulting binary into Git
without much hassle.  You might even want to make that a dynamically
loaded object.  The interface into a merge strategy is fairly narrow
IIRC.  Or possibly a new remote helper.

Adding a new refs backend may need to wait for the work Patrick is
doing to add reftable support, but once the abstraction gets to the
point to sufficiently hide the differences between files and reftables
backends, I do not see a reason why you cannot add the third one.

And more into the future, we might want to have an object DB
abstraction, similar to how we abstracted refs API over time, at
which time you might be writing code that stores objects to and
retrieves objects from persistent redis and whatnot in your favorite
language.

This is definitely a thing people will want to do.  I think Microsoft
had some code for Azure DevOps that stored their code in the cloud and
the refs database in a real database.  I can imagine that being a
valuable set of features people would want to implement in a variety of
environments, with all of the benefits of basing on upstream Git.

I also feel that I would absolutely not want to write those things in C.
Rust is much more ergonomic when writing these things because freeing
resources (freeing memory, rolling back transactions, closing files,
etc.) becomes as easy as implementing the Drop trait and you write less
boilerplate.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA