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

From: Patrick Steinhardt <ps@pks.im>
Date: Sep 8, 2025, 06:44 UTC
Message-ID: <aL57ONmEKTmqFhIZ@pks.im>
In-Reply-To: <CABPp-BGpdEP9+CTApknmGNO=b=66bFKVzWL2s3gmgCMtTBTjPA@mail.gmail.com>

On Sat, Sep 06, 2025 at 09:31:02PM -0700, Elijah Newren wrote:

Show 29 quoted lines

> 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.

Show 22 quoted lines

> >   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