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

[<rsbecker@nexbridge.com>]

On September 7, 2025 12:10 AM, Elijah Newren wrote:
>Sorry for the delay; life outside of work is challenging at the moment...
>

I am going to address the critical point mentioned below and snip the rest for brevity.

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

I do not see that distributors _must_ ship the latest version. Suppose we are on
2.51.0 and a CVE comes out that prohibits its use in an organization that does
not allow any medium-high to high CVEs. This represents hundreds of thousands
of impacted users in my community alone. How does the CVE get applied if the
latest cannot be built and the git team does not apply the CVE fixes to old
versions. Personally, I do not care if git versions are different between work
and home, or even between CI/CD and other platforms. I don't even care
if I have to use JGit instead of git in some situations (which I see is a likely
outcome of this discussion). Is there an official statement of what an LTS
means? In other projects LTS is typically, and formally by policy 5 years.
From what others have said here, positions of 6 months, 3 years, and
"apply it yourself if you want to continue to use git" have been made.

The core problem of adding a breaking dependency is when a CVE comes
out that prohibits git from being used at all. If the git team is not going
to provide a clear statement, one way or another, if how CVEs (at
whatever severity level) will not have a commitment of any kind,
then distributors are essentially cast adrift and on our own. It would
be helpful of those of us who donate our time, for no compensation,
are able to plan for this in a meaningful way. Please remember that
we have to justify our participation to our management teams to be
allowed to continue to participate. Nothing is free from this end
and if fixing (not just applying fixes) CVEs are now 100% our
responsibility, if would be critical to know that when we build our
business cases to our bosses, who I am fairly certain will say an
emphatic no.

Also remember that without support from the git team, the
code base is no longer the same, meaning the auditors will not
necessarily accept fixes from third-party sources. This particular
point enabled adoption on some platforms, particularly NonStop.
Adoption was at 1-2 customers when we had a divergent code
based because some platform fixes being different from the
standard code-base and could not be certified as valid. Once the
code-base because common, adoption was rapid and enthusiastic.
If this goes away, I suspect that adoption rates will go negative.
I am aware that that particular discussion is actually happening
in some organizations in my community right now, with companies
looking for alternatives to git based on this discussion thread.

With over a decade of respect and participation,
Randall