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

[Patrick Steinhardt <ps@pks.im>]

On Sat, Sep 06, 2025 at 09:31:02PM -0700, Elijah Newren wrote:
> On Fri, Sep 5, 2025 at 7:29 AM Patrick Steinhardt <ps@pks.im> wrote:
> > > 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.
> 
> I don't see how steps 1 & 2 help at all.  We now know we want to make
> Rust mandatory eventually, and should provide distributors and
> platforms as much notice as possible so they are aware.  But what
> you've proposed is another libgit-rs or libgit-sys -- an optional
> component that no one will know about unless they go looking for it.
> I don't see how those two steps provide any incremental help to
> anybody over what libgit-rs and libgit-sys have done.  From my point
> of view, Rust should be enabled by default in Git 2.52, with a simple
> knob provided to let distributors/platforms/users turn it off and
> build without it.

It helps because it allows us to slowly build out the infrastructure. We
don't yet need answers to every question that we currently have if we
initially have the Rust infra default-disabled.

I very much expect that there'll be some issues with our initial first
steps. So I'd rather want to avoid to expose developers or distros to
these issues directly, because that might train them to immediately
disable Rust right from the start.

> >   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.
> 
> I see your plan, but I agree with Phillip that I don't see why it
> makes sense to lump the Rust transition with the 3.0 transition.

I don't necessarily think we need to do it with 3.0, agreed. But as
Junio mentioned [1], 6 months feels too short for him to make Rust
mandatory, so we're realistically looking at a period of at least one
year to make this happen.

So it felt like a good match to tie these two together. The primary
motivation is that other breaking changes that we introduce with 3.0 may
cause minor inconveniences, as well. So that means that we help not only
non-Rust platforms with the proposed LTS release, but also potentially
others.

That being said, I really hope that most of the other changes should be
rather uneventful. I don't want to create a Python 3-style split.

> Setting that aside for a moment, the idea of Git 2.55 becoming 3.0
> seems like a good idea to me, assuming that doesn't rush brian on the
> sha1/sha256 interop (since I think that's probably the paramount
> feature of 3.0).

Yeah, the interop is definitely an important factor and the last part
that I think is still missing for Git 3.0 to become viable.

Patrick