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

From: Junio C Hamano <[email-masked]>
Date: Tue, 23 Sep 2025 10:29:46 -0700

Phillip Wood <[email-masked]> 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 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".