On Wednesday, January 10, 2024 5:12 PM, Junio C Hamano wrote:

Dragan Simic [off-list ref] writes:

quoted

Thus, Git should probably follow the same approach of not converting
the already existing code, but frankly, I don't see what would
actually be the "new leafs" written in Rust.

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.

Just a brief concern: Rust is not broadly portable. Adding another
dependency to git will remove many existing platforms from future releases.
Please consider this carefully before going down this path.
--Randall