Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Patrick Steinhardt <ps@pks.im>]

On Fri, Sep 19, 2025 at 08:41:45PM +0200, John Paul Adrian Glaubitz wrote:
> On Thu, 2025-09-04 at 16:26 +0200, Patrick Steinhardt wrote:
> > this small patch series introduces Rust into the core of Git. This patch
> > series is designed as a test balloon, similar to how we introduced test
> > balloons for C99 features in the past. The goal is threefold:
> > 
> >   - Give us some time to experiment with Rust and introduce proper build
> >     infrastructure.
> > 
> >   - Give distributors time to ease into the new toolchain requirements.
> >     Introducing Rust is impossible for some platforms and hard for
> >     others.
> > 
> >   - Announce that Git 3.0 will make Rust a mandatory part of our build
> >     infrastructure.
> 
> I'm one of Debian's maintainers in Debian Ports and I maintain Debian unstable
> on older and more obscure architectures such as alpha, hppa, m68k, sh4 and sparc64.
> 
> Of all the architectures in Debian, there are currently four architectures that
> don't support rustc. Those are alpha, hppa, m68k and sh4 [1]. For m68k, the
> situation is special as both LLVM and rustc already support m68k but with Linux
> still defaulting to 16-bit alignment on this architecture [2], building LLVM and
> rustc is currently not possible. I'm working on a switch to 32-bit alignment
> though which is default for NetBSD/m68k and also what specified in the official
> SysV ELF ABI documentation.
> 
> In general, I'm not against introducing Rust support into existing projects. However,
> I wished projects would be a little more patient until either the GCC codegen in
> rustc called rustc_codegen_gcc [3] or the Rust frontend in GCC have become ready
> for prime time.

Thanks for raising these concerns, I really appreciate that! Making
platform maintainers aware of this upcoming change was one of the goals
of announcing the breaking change in the first place, so I'm happy to
see that this discussion is happening now :) After all, we are aware
that the proposed change can create hardships for downstream
distributions and maintainers.

The timeline I have layed out right now is trying to cater towards
gccrs, at least to a certain extent. As Pierre-Emmanuel mentioned in
[1], gccrs _may_ start to become ready next year with a target version
of Rust 1.49. Given proposed timelines, Git 3.0 with mandatory Rust
would be released at the end of next year, which would hopefully be
after gccrs slowly becoming a viable alternative to compile Rust.

This is also the reason why I've picked Rust 2018 as the edition, as
Rust 1.49 doesn't know about any later editions.

Of course, given that the work on gccrs is driven by volunteers to the
best of my understanding I don't want to "force" them to get this done
by that point, and Pierre-Emmanual also made clear that the initial
release is still likely to have many bugs. So it may be the case that
gccrs or any other codegen is not ready yet at that point in time. If
so, we might have to reopen the discussion of whether or not we really
want to switch over to mandatory Rust with Git 3.0.

Ultimately, I guess that this will also depend on how much of a pain it
is for us to keep Rust non-mandatory. We don't have a lot of experience
with Rust in our codebase yet, but if we eventually see that it's a
breeze to keep it optional I think we should consider deferring the date
where it's becoming mandatory.

All to say: I don't think we should blindly pull the trigger with Git
3.0. I think we should take a more nuanced approach and consider:

  - Any of the learnings we had with the initial Rust infra and how hard
    it is to keep it optional.

  - The status quo of the ecosystem and whether we can expect either
    gccrs or rustc_codegen_gcc to become stable.

That being said, I think we should keep the current intent spelt out in
our breaking changes document so that we can get more feedback from
downstream maintainers that aren't currently aware of the porposed
upcoming change.

Thanks!

Patrick

[1]: <7bf054a1-0196-4ad8-aaa4-a432cd2c93a5@embecosm.com>