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

[Patrick Steinhardt <ps@pks.im>]

On Mon, Sep 08, 2025 at 11:33:45PM -0700, Elijah Newren wrote:
> On Sun, Sep 7, 2025 at 11:44 PM Patrick Steinhardt <ps@pks.im> wrote:
> >
> > 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:
> [...]
> > > > 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.
> 
> One of the things I find very unfortunate about this series, is we
> have a new contributor who was trying to send in patches, and instead
> of providing feedback, suggesting alternatives, or asking if he'd do
> it differently (which he actually said he was willing to do [1]), it
> sends out a competing patch series to replace his instead.  (And this
> happened shortly after someone else interjected patches because of
> interest in the first area he touched, forcing him to pivot once
> already[2].)  Further, despite him having solved how to get it running
> on all platforms we run in CI with some big help from the
> git-for-windows folks, this series discards all of that.  It lends to
> a feeling that he might be working on important and interesting
> topics, but his changes aren't welcome and it's not worth providing
> feedback for him to modify them to become so.  That's almost certainly
> not your intent, but that is the effect that sending a competing patch
> series likely is going to have.
> 
> [1] https://lore.kernel.org/git/CAH=ZcbBLAKaE733_2_2qbFTYCfwGq37RfF-Z3vaKL1ZR49msAA@mail.gmail.com/
> [2] https://lore.kernel.org/git/xmqqzfbvfxs6.fsf@gitster.g/

First to say: I'm not trying to say that his changes are not welcome
here. What I'm trying to do with my patch series is to reconcile the
different camps that we have in our project and to find a way forward so
that Ezekiels work eventually becomes unblocked.

And regarding the Windows changes: yes, I haven't picked those yet. I
wanted to first get to a minimum working proposal so that we can focus
the discussion more on the roadmap, which I think is the more important
discussion compared to the technical discussion.

As I mentioned, I do plan to implement Windows support as a next step
once we have agreed on the initial baseline.

Patrick