Re: [PATCH v5 7/9] BreakingChanges: announce Rust becoming mandatory

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Sep 18, 2025, 01:19 UTC
Message-ID: <aMteF4VTq2C5sAhK@fruit.crustytoothpaste.net>
In-Reply-To: <aMsxhp6ZO2Cdz7+k@szeder.dev>

On 2025-09-17 at 22:09:10, SZEDER Gábor wrote:

Show 10 quoted lines

> Providing an LTS release for those platforms that can't jump on the
> Rust bandwagon is great, but...
> 
> Git 3.0 will switch the default hash algorithm for newly initialized
> repositories to SHA-256, which, presumably, will also encourage SHA-1
> -> SHA-256 migrations in existing repositories.  Alas, it appears that
> the SHA-1/SHA-256 interop feature will only be available in Rust.
> 
> How will this affect those platforms without Rust?  What will and
> won't work on such platforms?

On Git 3.0, nothing will work without Rust because it will be mandatory. However, people who want to perform the conversion can do that by booting a Linux VM[0] and converting the repository there, then pushing it somewhere. The only inconvenience is that you'll have to have a flag day for working with the repository on older Git: you won't be able to dynamically pull from or push to a repository with a different main algorithm than you.

One of my first patches is that setting extensions.compatObjectFormat without Rust will simply die and say that's not supported. If that config value is unset, then Git up to 3.0 will simply function as normal, so full single-hash compatibility is assured. We already have that: SHA-256 repositories work just fine with SHA-256 remotes and SHA-1 repositories work just fine with SHA-1 remotes, but they're currently not interoperable.

> I think it should be called out explicitly in the justification that
> whatever limitations this imposes on those platforms with respect to
> hash function transition, the project has duly considered that and is
> OK with it.

I am fine with this and I don't think this is a problem.

I will mention that I have also already written the code in Rust and it is elegant and tidy and more efficient, better tested, and shorter than the equivalent C code. Writing the code also took much less time than the equivalent C code would have. I am not planning to rewrite it in C, since I already have a substantial amount of other interoperability work to do, so unless someone else is planning on doing so, the project has two choices: use the Rust code and accept that, or decide that they don't want the interoperability work for Git 3.0.

I want to point out that so far, all of the SHA-256 work, including the interoperability work, has been on my own time. I understand that my contributions to the project have to be acceptable to the project, but I also am not willing to rewrite a bunch of work because we already decided that we were going to do something and then changed our mind. If the project wants to be fickle on this matter, then other contributors can do the interoperability work on those terms.

I realize the decision to incorporate Rust was made recently, but the binary loose object maps are a blocker for some of the protocol work I'm doing, and if we want the interoperability functionality in Git 3.0 in a year, then I can't afford to wait here, since this kind of discussion tends to drag on extensively.

[0] Debian actually offers multiarch support, so as long as Debian has support for the architecture you're running on, you can boot a Debian VM of your native architecture, install amd64 or arm64 packages and QEMU, and then run those binaries in emulation. It will be slow, but it works for virtually all architectures. I've done something similar with risc64 containers on my amd64 laptop.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA