From: rsbecker@nexbridge.com
Date: Wed, 10 Jan 2024 22:15:53 GMT
Subject: RE: [DISCUSS] Introducing Rust into the Git project
Message-ID: <006b01da4412$96c6c500$c4544f00$@nexbridge.com>
In-Reply-To: <xmqqjzog96uh.fsf@gitster.g>

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