On Fri, Sep 5, 2025 at 4:51 AM Patrick Steinhardt <ps@xxxxxx> wrote: > > Over the last couple of years the appetite for bringin Rust into the > codebase has grown significantly across the developer base. Introducing > Rust is a major change though and has ramifications for the whole > ecosystem: > > - Some platforms haven't yet been able to implement a Rust toolchain, > even though it is possible in theory. > > - Some platforms don't have any support for Rust at all. > > - Some platforms may have to figure out how to fit Rust into their > bootstrapping sequence. > > Due to this, and given that Git is a critical piece of infrastructure > for the whole industry, we cannot just introduce such a heavyweight > dependency without doing our due diligence. > > Instead, preceding commits have introduced a test balloon into our build > infrastructure that convert one tiny subsystem to use Rust. For now, > using Rust to build that subsystem is entirely optional -- if no Rust > support is available, we continue to use the C implementation. This test > balloon has the intention to give distributions time and let them ease > into our adoption of Rust. This paragraph appears to contradict itself -- it says we introduced a test balloon, but then explains how the test balloon isn't actually a test balloon (i.e. that we simply silently use the C implementation if Rust isn't available). > Having multiple implementations of the same subsystem is not sustainable > though, and the plan is to eventually be able to use Rust freely all > across our codebase. As such, there is the intent to make Rust become a > mandatory part of our build process. > > Add an announcement to our breaking changes that Rust will become > mandatory in Git 3.0. A (very careful and non-binding) estimate might be > that this major release might be released in the second half of next > year, which should give distributors enough time to prepare for the > change. While I disagree with lumping the change with 3.0, I appreciate the goal to provide additional notice. I think it really ought to be part of the release notes for 2.52 instead of the BreakingChanges document, but having some kind of announcement is the most important part. Thanks for proposing some wording. > Signed-off-by: Patrick Steinhardt <ps@xxxxxx> > --- > Documentation/BreakingChanges.adoc | 36 ++++++++++++++++++++++++++++++++++++ > 1 file changed, 36 insertions(+) > > diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc > index f8d2eba061..dbb15b6a57 100644 > --- a/Documentation/BreakingChanges.adoc > +++ b/Documentation/BreakingChanges.adoc > @@ -165,6 +165,42 @@ A prerequisite for this change is that the ecosystem is ready to support the > "reftable" format. Most importantly, alternative implementations of Git like > JGit, libgit2 and Gitoxide need to support it. > > +* Git will require Rust as a mandatory part of the build process. While Git > + already started to adopt Rust in the Git 2.52, all parts written in Rust are > + optional for the time being. This includes: This isn't quite accurate; perhaps: ...While Git already started to adopt Rust into the core in Git 2.52 (and as an optional "contrib" component back in Git 2.49), all parts... > ++ > + ** Subsystems that have an alternative implementation in Rust to test > + interoperability between our C and Rust codebase. > + ** Newly written features that are not mission critical for a fully functional > + Git client. > ++ > +These changes are meant as test balloons to allow distributors of Git to prepare > +for Rust becoming a mandatory part of the build process. There will be multiple > +milestones for the introduction of Rust: > ++ > +1. Initially, with Git 2.52, support for Rust will be auto-detected by Rust and > + disabled in our Makefile so that the project can sort out the initial > + infrastructure. > +2. In Git 2.53, support for Rust will be made mandatory in case Git is compiled > + with breaking changes. Breaking changes can be enabled for Meson by saying > + `meson configure -Dbreaking_changes=true` and for Makefiles via `make > + WITH_BREAKING_CHANGES=YesPlease`. It will still be possible to compile with > + breaking changes, but explicitly disable Rust. As stated in https://lore.kernel.org/git/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@xxxxxx/T/#mf9283df5e7724fd00a6fe23e1777b77fcdf0c12d, I don't see how these two step help at all, and think we should jump straight to step 3 with Git 2.52. > +3. In Git 2.54, both build systems will default-enable support for Rust so that > + builds will break if Rust is not available on the build host. The use of Rust > + can still be explicitly disabled via build flags. > +4. In Git 3.0, the build options will be removed and support for Rust is > + mandatory. > ++ > +You can explicitly ask both Meson and our Makefile-based system to enable Rust > +by saying `meson configure -Drust=enabled` and `make WITH_RUST=YesPlease`, > +respectively. I think we should instead allow folks to ask Meson and Maskfile to disable Rust, otherwise we haven't provided a test balloon yet. > ++ > +The Git project will declare the last version before Git 3.0 to be a long-term > +support release that is maintained until alternate Rust backends like gcc-rs are > +able to build Git. The Git project may need to rely on distributions to help > +with identifying and backporting important bugfixes. I disagree with tying the timeline to gcc-rs being able to build git; I think that part of this paragraph should be stricken.
