Re: [PATCH 0/7] RFC: Accelerate xdiff and begin its rustification

> Hi,
>
> On Tue, Jul 22, 2025 at 9:03 AM Sam James <sam@gentoo.org> wrote:
>
> First of all, thanks to all the Gentoo folks for chiming in and
> providing specifics about platforms and their state.

>
>> > I am far from a Rust expert, but I think that a more modern, memory-safe
>> > language will attract newer contributors who may have a fresher
>> > perspective on the project, and I think that's a good thing.
>>
>> Aren't they likely to contribute to gitoxide? There, they get a clean
>> slate without having to deal with the least-fun part (bidings).
>
> I'm sure some are.  But clearly there are others where the draw is
> improving git itself because of its installed base; in fact, we need
> look no further than this exact series we are commenting on to find
> proof of that -- one such new contributor submitted patches to use
> Rust in git, and found a significant speedup while doing so.

>
> Further, there's considerable interest from existing git developers to
> use Rust in git as well; last year at the Git contributor summit,
> usage of Rust in git was not only one of the topics of discussion, it
> was the top voted topic (meaning, the topic that the greatest number
> of git contributors wanted to discuss).
>
>> > It is also not the Git project's responsibility to ensure that every
>> > platform is Rust-friendly.
>>
>> That's true, of course. And nobody is entitled to indefinie updates, but
>> on the other hand, there's still some implicit contract with users. I
>> really don't think git would have the adoption it does today if it had
>> adopted a Rust-like language in the same state Rust is now from the
>> start.
>>
>> (In exactly the same way, git doesn't gratuitously break compatibility
>> every release either. Can it? Yes, and git can change the platforms it
>> runs on, but it's something to be taken seriously.)
>
> This feels kind of close to a false dichotomy between breaking
> compatibility every release and indefinite update entitlements.  There
> is certainly some middle ground: discussing reducing the breadth of
> platform support in order to gain other benefits, then gathering
> feedback, making a plan, and announcing the upcoming change, etc.
>

> And we're already pretty deep into it.  Concerns about losing out on
> some platforms have repeatedly slowed us down from adopting Rust years
> ago.  Yet, the desire for Rust adoption keeps coming up anyway; see
> the threads starting at
>
>   * https://lore.kernel.org/git/ZZ77NQkSuiRxRDwt@nand.local/
>   * https://lore.kernel.org/git/Zu2D%2Fb1ZJbTlC1ml@nand.local/
>   * https://lore.kernel.org/git/20241128-pks-meson-v10-22-79a3fb0cb3a6@pks.im/
> (search for "Rust")
>   * https://lore.kernel.org/git/cover.1723242556.git.steadmon@google.com/
>
> The discussion has also been picked up and reported outside the Git
> mailing list, e.g. https://lwn.net/Articles/998115/.
>
> And so, in addition to the optional contrib/libgit-rs and
> contrib/libgit-sys Rust components that have already been merged into
> git, and a new build system added in part to make it easier to adopt
> Rust, we now have the first patch series that proposes a hard
> dependency on Rust.

> and
> feel Rust would help (see e.g.
> https://litchipi.github.io/infosec/2023/01/24/git-code-audit-viewed-as-rust-programmer.html
> and https://github.com/bk2204/git/commit/fbeb1180c7473635a964daed2da642c53487782d).
> We're responsible for performance of Git for our users, and feel Rust
> would help (see the email that started this thread,
> https://lore.kernel.org/git/CABPp-BFOmwV-xBtjvtenb6RFz9wx2VWVpTeho0k=D8wsCCVwqQ@mail.gmail.com/,
> and brian's notes about [CPU multi-]threading elsewhere in this email
> thread we are in).  And there are other benefits from using Rust that
> we believe would benefit our users.  Thus, it's not just a question of
> responsibility to our users, because such a responsibility pulls us in
> different directions regarding usage of Rust.  So we need to figure
> out how to weigh the needs of our different users.  For many of us,
> and forgive the geeky comparison, we'll probably weigh those needs
> with something more akin to an L2 norm (most good for the most users)
> rather than an L-infinity norm (maximal difference in usability for a
> single user), which probably isn't to your liking.
>

> Anyway, there's been lots of discussion already.  We can certainly
> still discuss more about exactly how to announce, when to adopt Rust,
> whether we'll support an existing C-only version of git for a longer
> period of time than normal, and even whether to continue to delay
> adopting Rust for a little longer.  But my personal guess is that
> attempting to stop adoption of Rust is unlikely to win at this point.

>
>> > Hopefully the platforms that we currently support but won't after this
>> > patch series have niche enough workloads that they do not need the
>> > absolute latest-and-greatest Git release at all times.
>>
>> I mention this in my other email, but it's not just about ancient
>> platforms. It's also about new ones, or ones where Rust supports them
>> poorly despite them being relevant.
>
> This feels like you're trying to push the decision for a given
> platform to be a dichotomy between latest-and-greatest-Git or
> no-version-of-Git-at-all, despite the fact that Taylor suggested an
> alternative and you even quoted him.  Can you comment on that
> alternative?  Why would using the last C-only version of Git[1] until
> gccrs bridges the gap be a problem for these platforms?