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

[Taylor Blau <me@ttaylorr.com>]

On Thu, Jul 17, 2025 at 09:51:32PM +0000, brian m. carlson wrote:
> 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.

I agree. I don't think that there is ever going to be a "perfect" time
to introduce a hard dependency on Rust, and I don't think that should
hold the project back from adopting it.

I am far from a Rust expert, but I think that a more modern, memory-safe
language will attract newer contributors who may have a fresher
perspective on the project, and I think that's a good thing.

The alternative, of course, is to continue to use C and not take any
dependency on Rust. I think there is a middle-ground in there somewhere
to be able to build with (e.g.) "make" or "make RUST=1", but I would
really like to see the project take a firmer stance here.

I worry that having build support for both "with Rust" and "C only" will
create a headache not just at the build system level, but also in the
code itself. Having a patchwork of features, optimizations, or bug fixes
that either are or aren't supported depending on whether Rust support
was specified at build-time seems like a worst-of-all-worlds outcome.

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

Agreed. Of course, I think we would all like Git to be able to build and
run on as many platforms as is reasonably possible. But we cannot
support all platforms for all time. It is also not the Git project's
responsibility to ensure that every platform is Rust-friendly.

Hopefully the platforms that we currently support but won't after this
patch series have niche enough workloads that they do not need the
absolute latest-and-greatest Git release at all times.

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

Yeah, I think that this is the most interesting part of the discussion
here. I am not knowledgeable enough about Rust's release cadence and
platform compatibility to have an opinion here. But I trust brian's
judgement ;-).

Thanks,
Taylor