Re: [PATCH v5 0/9] Introduce Rust and announce that it will become mandatory
- From
Elijah Newren <newren@gmail.com>
- Date
- Sep 18, 2025, 03:47 UTC
- Message-ID
- <CABPp-BEiK49f_UB5UPe3qM9O7vQGGFJ8Nshw1f6W_6Lw7HRL6Q@mail.gmail.com>
- In-Reply-To
- <20250915-b4-pks-rust-breaking-change-v5-0-dc3a32fbb216@pks.im>
Hi Patrick,
On Mon, Sep 15, 2025 at 4:23 AM Patrick Steinhardt <ps@pks.im> wrote:
Show 90 quoted lines
> > Hi, > > 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. > > The test balloon itself is quite uninteresting: I've chosen to convert > the "varint.c" subsystem, mostly because it is trivial and does not have > any dependencies. But it does allow us to verify that C to Rust interop > works as expected, and to play around with tooling. All tests pass with > the "varint.rs" implementation. > > For now, the series only contains support for Meson. If we agree to go > down this route I'll also introduce support for Rust into our Makefiles > at a later point in time. > > Furthermore missing is additional tooling: > > - At least one CI job to verify that Rust builds and works as > expected. > > - Tooling and CI jobs to ensure that we have consistent formatting via > `cargo format`. > > And probably lots more. As said, the entire goal is for us to have an > easy playground that we can experiment on and develop the infrastructure > incrementally without yet having to commit to anything. > > I'm mostly splitting out the topic of introducing Rust from the larger > series that introduce it into xdiff so that we can focus more on the > actual process of introducing Rust into Git and less on the potential > features that we want to build on top of it. > > Changes in v2: > - Introduce support for building the Rust library via our Makefile. > - Introduce a '-DWITH_RUST' define. This define is used to print > whether or not Git is built with Rust via `git version > --build-options`. > - Adjust Meson to not depend on v1.9.0 and newer anymore. > - Introduce a roadmap into our BreakingChanges document to explain how > we'll iterate towards mandatory Rust support. > - Rework the Fedora job to do a full compile-and-test run with Meson > and breaking changes enabled. > - Adapt our breaking-changes jobs to enable Rust support. > - Link to v1: https://lore.kernel.org/r/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im > > Changes in v3: > - Reorder all uses of `WITH_RUST` after the include of "config.mak". > - Add a test to verify overflow behaviour in Rust and explicitly use > `add_wrapping()`. > - Use explicit dependencies for the Rust library in our Makefile. > - Fix Alma Linux CI job. > - Stop tying maintenance of our LTS release to the availability of > gcc-rs. > - Add a fallback to Meson to use cargo directly. > - I've fixed the Rust edition to 2018 for now. This is intentionally > conservative so that we might be able to use Rust 1.49. For now, we > don't have any reason to use a newer edition, either. So let's take > the oldest version we can live with for now and then bump it as > required. > - Link to v2: https://lore.kernel.org/r/20250905-b4-pks-rust-breaking-change-v2-0-6939cbf4a0b8@pks.im > > Changes in v4: > - Convert "varint.c" to use explicit integer width so that we don't > need to use C types in Rust. > - Adapt Meson to unconditionally use Cargo. > - Don't use the unstable `--out-dir` option in Cargo. Instead, we > resort to a wrapper script in Meson. > - Shorten the timeline a bit to drop the extra step that ties Rust > support to `-Dbreaking_changes=true`. This accelerates the timeline > until distros are made forcibly aware of the upcoming changes in > Rust. > - Link to v3: https://lore.kernel.org/r/20250908-b4-pks-rust-breaking-change-v3-0-1cd7189fed3b@pks.im > > Changes in v5: > - Fix indentation in the BreakingChanges document. > - Fix a commit message typo. > - Include "Cargo.lock" in the `make clean` target again. > - Link to v4: https://lore.kernel.org/r/20250910-b4-pks-rust-breaking-change-v4-0-4a63fc69278d@pks.im
Patch 7 still has the same error as v2; could we get the wording corrected? I suggested an alternative already[*]:
"...While Git already started to adopt Rust in Git 2.52, all parts..."
=>
"...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..."
Also, as discussed over at https://lore.kernel.org/git/xmqqy0qcae6z.fsf@gitster.g/, would you be willing to re-roll a single-patch v6 (with just your updated patch 7), and let Junio merge that? That would get the important timeline that you wanted landed, and then Ezekiel could pull your varint and help changes together with brian's Documentation change and Johannes' git-for-windows change to create a test balloon and introduce Rust and have it build on all CI'd platforms.
Thanks, Elijah