Subject: Re: [PATCH v3 02/15] xdiff: introduce rust

From: Sam James <[email-masked]>
Date: Tue, 02 Sep 2025 19:47:00 +0100

"brian m. carlson" <[email-masked]> writes:

> On 2025-09-02 at 11:16:19, Patrick Steinhardt wrote:
>> As Pierre-Emmanuel menitoned in [1], the backend is likely to stabilize
>> next year. One or two years of backports for that particular LTS version
>> doesn't feel too bad. And if it does become more involved we can maybe
>> also distribute the load and rely on maintainers of impacted platforms
>> without Rust to help out with the backporting.
>
> I'm very much in favour of supporting gccrs when it's available, but I
> also want to say that it currently is targeting 1.49, which is much
> older than we want.  It's also not necessarily going to be fully usable
> or bug free in that amount of time.
>
> I also want to point out that it's important that the maintainers of
> affected platforms build the tooling necessary for their platforms to be
> supported.  I'm not seeing ports of LLVM to those architectures or
> contributions to gccrs that would make those platforms easier to
> support.

This isn't accurate. gccrs doesn't need particular porting to arches: at
least not yet, and if it does, it'll be very minor; any changes of this
sort will be in crates themselves which would go upstream.

As for the libgccjit-based backend for rustc, see
https://github.com/rust-lang/rustc_codegen_gcc/issues/49,
https://github.com/rust-lang/rustc_codegen_gcc/issues/744, and
https://github.com/rust-lang/rustc_codegen_gcc/issues/742 for discussion
and complications. But to say that nobody is doing it or working towards
it is inaccurate.

>
>> Also, all of this feels like a significant shift. I'm strongly in favor
>> of adopting Rust in our codebase, but I think we should do so carefully.
>> So we might take it extra carefully and say that Rust will become a
>> mandatory dependency in Git 3.0, where the last release before Git 3.0
>> will become an LTS release.
>
> I'd prefer we not wait that long.  I'm doing some work in building the
> new loose object mapping using Rust and it's much more efficient than
> writing it in C because we don't have to sort the data when we use a
> BTreeMap.  The code is much simpler, shorter, and easier to write.
>

I still think adopting Rust is a compatibility break and a "breaking
change". Again, keeping in mind that for adopting C99 features (!), the
Git project used "test balloons" very very recently.

> Nobody else is currently working on the interoperability code and we
> expressed that we ideally wanted it for Git 3.0.  Being able to use Rust
> means I can write that code faster, with fewer errors (and hence less
> debugging time), and better tests.  Otherwise, I'm afraid that it will
> take longer and we might not have it fully upstream for Git 3.0.
>
> We also have this series right now, which we'd have to abandon if we're
> not going to support Rust right away.  I'd like to retain Ezekiel as a
> contributor and incorporate Rust, and I think the best time to adopt
> Rust is now, not at Git 3.0.

I think there's going to be various issues that arise even on platforms
that support Rust that would make it fitting for Git 3.0, at least for
the first few releases that incorporate Rust. I'll note that the series
isn't currently using Meson's Rust integration as QEMU is doing.

sam