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