Re: [PATCH 0/7] RFC: Accelerate xdiff and begin its rustification

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 3285 bytes --]

On 2025-07-17 at 20:32:17, Ezekiel Newren via GitGitGadget wrote:
> This series accelerates xdiff by 5-19%.

That's great.

> It also introduces Rust as a hard dependency.

I think that's fine.  We already discussed doing this at the last
Contributor Summit in Berlin and everyone was in favour.  While we did
not have every contributor represented, I think that unanimity of the
contributors present is a compelling enough reason.

> …and it doesn’t yet pass a couple of the github workflows; hints from
> Windows experts, and opinions on ambiguous primitives would be appreciated
> (see below).
> 
> This is just the beginning of many patches that I have to convert portions
> of, maybe eventually all of, xdiff to Rust. While working on that
> conversion, I found several ways to clarify the code, along with some
> optimizations.
> 
> So...
> 
> This obviously raises the question of whether we are ready to accept a hard
> dependency on Rust. Previous discussions on the mailing list and at Git
> Merge 2024 have not answered that question. If not now, will we be willing
> to accept such a hard dependency later? And what route do we want to take to
> get there?

Again, I think that's fine.

I have a proposed policy at [0] (available from the `rust` branch on
that remote).  Included in that policy is a link to [1], which I
summarize as "the U.S. government is proposing to classify development
in memory unsafe languages as a Product Security Bad Practice."  The
proposal is that a memory safety roadmap be introduced by the end of
2025.

Now, do let me be clear that I don't agree with everything that the U.S.
government says or does (far from it), but I do think this is a sensible
proposal (or I wouldn't have cited it) and it will be showing up in a
lot more security standards coming down the line, especially for those
forges and companies which will be selling to governments around the
world.  There's no time like the present to do this.

I realize that that means that we will lose support for some platforms.
I ultimately think that it's up to the porters and maintainers for a
platform to maintain appropriate toolchains on that platform and that,
while we should be cognizant of the requirements for adding new
platforms or architectures, that shouldn't prevent the inclusion of
important new tools like memory-safe languages.

I would like to see a change to our platform policy and a policy on Rust
before we merge this.  I know your series adds support for 1.87, but
because distros don't run the latest toolchain, we had discussed in the
past targeting Debian stable's version plus an additional year after the
new release.  This means we'll support a Rust version for three years,
which is a reasonable amount of time for a toolchain and allows distros
to easily backport security fixes.

If you would like, you are welcome to use my proposed policy as a basis
for this, or I can send that out as a separate document if you don't
want to write one or revise mine.

[0] https://github.com/bk2204/git/commit/fbeb1180c7473635a964daed2da642c53487782d
[1] https://www.cisa.gov/resources-tools/resources/product-security-bad-practices
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]