On Fri, Sep 05, 2025 at 03:14:25PM +0100, Phillip Wood wrote:
> On 05/09/2025 12:50, 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.
>
> These sound good
>
> > - Announce that Git 3.0 will make Rust a mandatory part of our build
> > infrastructure.
>
> I'm not sure if we really want to wait that long. So far Git 3.0 has been
> about user facing changes rather than build requirements. In [1] I suggested
> a period of six months from the initial announcement to making rust
> mandatory to allow distributors time to either adjust their build procedures
> or notify their users that they will only be offering security updates in
> the future.
More on that below.
> > 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.
>
> It looks like this version does include the necessary Makefile changes which
> is great. I do think though, that for the test balloon to be valuable, we
> need make building with rust the default with an error message that tells
> people how to build without rust if that fails. Otherwise it is easy for
> people building on platforms without rust support to miss that we're going
> to be making it mandatory soon.
I have a plan layed out in the BreakingChanges document that mentions
how I'm proposing to do the transition:
1. We introduce it with auto-detection for Meson and default-disabled
for our Makefile in Git 2.52.
2. We enable Rust by default in case WITH_BREAKING_CHANGES is enabled
in Git 2.53.
3. We always enable Rust by default in Git 2.54.
4. We unconditionally enable Rust in Git 3.0.
This is basically gradually tightening the screws, which both gives us
time to build the infra and gives downstream time to become aware of the
change and adapt.
I think making it mandatory in Git 3.0 makes sense because I also
propose to make the last version without mandatory Rust be an LTS
version. And if we connect that with it being the last version before
3.0 I think that's an additional benefit, as there will be other
breaking changes in 3.0.
In the end it kind of hinges on when we think we want to release Git
3.0. If we can agree on the above plan, we could also think about making
Git 2.55 become 3.0 instead. That'd be in a bit less than a year from
now, which I think is a good timeframe for that breaking release. I
personally don't see a reason to push it out into the future for way
longer than that, and it would be good anyway if we built some consensus
around its release date.
Patrick
