Re: [PATCH v3 02/15] xdiff: introduce rust

[Patrick Steinhardt <ps@pks.im>]

On Sat, Sep 06, 2025 at 09:10:28PM -0700, Elijah Newren wrote:
> On Thu, Sep 4, 2025 at 11:50 PM Patrick Steinhardt <ps@pks.im> wrote:
> > The problem here is that we don't have a story to tell yet. I agree that
> > not everyone always needs the latest and greatest, which is also why I
> > mentioned that I think it's fine for _new_ features to be developed in
> > Rust right away.
> >
> > But the story is altogether different for bug and security fixes.
> >
> >   - We of course backport security fixes, but would that also be the
> >     case if we had ported the subsystem to Rust already and now had to
> >     implement the security fix twice?
> >
> >   - What happens if only the old C version has a security bug? Do we
> >     still fix it?
> >
> >   - Likewise, what happens with important bug fixes? We tend to backport
> >     those that are easy-ish to backport, but if people are potentially
> >     stuck with an older Git version for years it will become harder for
> >     us to do so.
> >
> > I think without us having a proper answer to these questions we _are_
> > pulling the rug away. Distros may be stuck with an old version of Git
> > for a significant time, and from my point of view we have to do a couple
> > of compromises there.
> 
> These are good questions...but they are ones to which I suspect
> delaying will not provide the answer.  In fact, I don't think we'll
> _ever_ have the answer to these questions, no matter how much we delay
> or discuss.  Traditionally, if an issue was more severe, it has been
> backported to more versions, even if the backport wasn't trivial.
> There's a cost/benefit tradeoff to be had for each vulnerability, and
> changes to the area making backports either be easy or hard always
> need to be weighed against the severity of the vulnerability.  I don't
> see that changing, and overpromising hurts in the long run probably
> more than having no guidance.  I just don't see us coming up with
> "proper answers" (which I'm guessing means fully spelled out answers?)
> to these questions ahead of time.

That's fair, I guess. I don't think we need to fully spell out the
answer to each of these questions. But I think we should have some
general alignment on how we'll handle the last non-Rust release, and
what some guarantees are that we can and want to provide.

> The answer to all of them is
> probably "we'll weigh the severity of the issue and the cost to
> backport and give the last C-only version significant extra weight in
> our considerations".  I doubt we'll ever be able to promise any more
> detail than that until we get concrete cases; I'm not even sure that
> this statement is acceptable to everyone on the list from the
> overpromising angle despite being as incomplete as it is.

True, we don't want to overburden us, either. This is mostly why I
proposed the compromise of saying "We provide you with updates for the
LTS version for X amount of time. If you still depend on it after that
time, we will be happy to pass over maintainership of that branch to the
community."

[snip]
> I still don't see why distributors _must_ ship the latest version of
> Git and why folks on some platforms are considered broken if they are
> using a slightly older version.  Let me ask again: has anyone answered
> why this is considered mandatory?  If they have, I've missed it, but
> I've asked multiple times.  Even if you want to lump "distributors
> cannot build a newer version" under the umbrella of "breaking
> changes", I argue it's a much different kind of break and one which
> merits different timelines for handling than e.g. lumping it in with
> 3.0.

To me it's not necessarily about the _latest_ version, rather about
_any_ version. Some distributions will not be able to build Git at all
anymore, so they are stuck at the last non-Rust version for the time
being. And seeing that the timeline is years for them to get Rust
support they may not be on a slightly older version, but on an ancient
version eventually.

So the question to me is less whether users of that distro will miss out
on new features, which I think is acceptable. Hence my statement that it
is fine from my point of view for new features to be written in Rust
immediately.

    NB: There's some nuance here. If newer features mean that users
    cannot interact with modern upstreams anymore the picture would
    change quite significantly. But the only work that really comes to
    my mind is SHA256, which already exists. I don't know whether the
    interop code may fall into this category, I hope it doesn't.

But the bigger question is whether that old version still gets security
updates and important bug fixes. If the only available non-Rust version
is riddled with security holes then these distros won't be able to
provide it at all anymore.

> > > (4) you suggest that adding Rust as an optional component should avoid
> > > the problem, yet we've already had Rust as an optional component for
> > > the last three releases, going back to 2.49.0.  (libgit-rs and
> > > libgit-sys).
> >
> > I don't really think that either libgit-rs or libgit-sys help in any
> > way. These are part of "contrib/", not built by default, and neither are
> > they consumed by anyone out there. So there is no reason for anyone to
> > build that library to the best of my knowledge.
> 
> I'm fully willing to accept they are inadequate notice (and perhaps
> even barely helpful), but disagree with the characterization that they
> don't help at all:
>   * they were consumed in the past by Google
>   * they recently received patches from someone outside Google
> (https://lore.kernel.org/git/20250826233525.2635432-1-davvid@gmail.com/)
>   * they were mentioned in the release notes highlighting at a minimum
> that Rust is being added to Git.
>   * they were highlighted in blog posts from both GitLab and GitHub as
> being noteworthy new things in the v2.49.0 release

Okay, fair.

> I agree with you there is certainly more we can do, and I like your
> idea of a test ballon.  Let's just avoid repeating the problem of
> adding an optional component that no one will try to build except for
> those for whom we know can build it; doing that would provide no more
> notice and thus provide no incremental benefit over libgit-rs and
> libgit-sys.

Fully agreed. My current proposal includes several steps of how we
tighten the screws here, where we gradually start to require Rust by
default on more platforms. Before Git 3.0 it's still possible to opt
out, but eventually distributors need to opt out explicitly. So that
should hopefully alert them that something is cooking.

Patrick