On Thu, Sep 4, 2025 at 10:30 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: s/bringin/bringing/ > 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. If it's entirely optional and automatically disabled on platforms which don't have Rust installed/available, then it isn't a test balloon, is it? All previous test balloons in this project were architected in such a way that Git would fail to build if the platform in question lacked the feature being "test-ballooned", and the idea was that packagers of those systems would alert the Git project about the problem or somehow resolve it themselves via the platform's local build infrastructure. However, with the approach implemented here, Git will build as usual on all platforms on which it already builds successfully, which means that the Git project is unlikely to hear complaints from packagers, especially if packagers haven't followed the relevant discussion threads and are unaware that a Rust test is being conducted. Moreover, the project has already heard from some packagers/maintainers that Rust support is lacking or (currently) impossible, so the project already has the sort of knowledge that a test balloon is intended to elicit. That's not to say that the changes implemented by this series can't be valuable, but rather that for these patches to be valuable, you probably need some way to advertise the test more loudly so that packagers actually attempt the Rust build. One possible way to rectify this shortcoming would be to enable the Rust code by default in the Git project but give packagers a way to opt out of it if they can't make it work on their platforms. > 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. > > Signed-off-by: Patrick Steinhardt <ps@xxxxxx>
