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

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

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

On 2025-09-17 at 22:09:10, SZEDER Gábor wrote:
> 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

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