On Wednesday, January 10, 2024 5:12 PM, Junio C Hamano wrote: >Dragan Simic <dsimic@xxxxxxxxxxx> writes: > >> 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
