Re: [PATCH v6 7/9] BreakingChanges: announce Rust becoming mandatory

[Patrick Steinhardt <ps@pks.im>]

On Tue, Sep 23, 2025 at 10:29:46AM -0700, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
> >> +We will evaluate the impact on downstream distributions before making Rust
> >> +mandatory in Git 3.0. If we see that the impact on downstream distributions
> >> +would be significant, we may decide to defer this breaking change to a
> >> +subsequent minor release. This evaluation will also take into account our own
> >> +learnings with how painful it is to keep Rust an optional component.
> >
> > I think this last paragraph is a welcome addition as it makes it clear
> > we're not going to blindly pursue rust if it causes widespread
> > problems. Personally I'd say "experience" rather than "learnings" but
> > that's probably me being a grumpy pedant.
> 
> If this transition turns out to be way too disruptive even for the
> 3.0 that promises big changes anyway, can "this breaking change"
> realistically be "deferred" to a subsequent "minor" release?
> 
> The only way I can think of that is permissible in a minor release
> would be to pear it down so much that it no longer is disruptive,
> but that would be very different from "this breaking change"
> anymore.
> 
> Or is this talking about waiting until the downstream distribions
> either die out without adding Rust support or start supporting Rust?
> That, except for the risk of having to wait forever, might work, but
> then to surviving distros, it would no longer be a "breaking" change
> even if we ship the same change as "this breaking change", right?

I guess the answer is "it depends". We're counting on tools like gccrs
and rustc_codegen_c to become viable, as those tools may help us quite
significantly to reduce the blast radius. But "reduce" doesn't
necessarily mean that there are no victims anymore.

I'll slightly reword this to say "this change" instead of "this breaking
change" though.

> I don't know.  To me, the last sentence sounds like reserving the
> right to later say "we learned that trying to support opt-in Rust
> component that we have to (partially) replicate in C is so painful,
> so we won't keep Rust an optional component".

We haven't gained a lot of experience with Rust yet, so I think we
should keep all options open for now. I really want the Rust experiment
to succeed (well, otherwise I wouldn't push this series), but we simply
don't know how it'll play out at this point.

Patrick