Re: When should we release Git 3.0?

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Oct 2, 2025, 22:33 UTC
Message-ID: <aN7917RSHBz3IV5o@fruit.crustytoothpaste.net>
In-Reply-To: <E03F997F-1738-4CF6-B7D5-206183FA5BD1@gmail.com>

On 2025-10-01 at 07:13:12, Luca Milanesio wrote:

Show 7 quoted lines

> > I personally do not want the interoperability work to be a blocker.  I
> > haven't really heard other commitments of contributors who want to work
> > on it and I don't really want to have to run full tilt trying to get it
> > out.  However, some other people may feel differently, in which I case I
> > encourage their participation in the project.
> 
> Sure, happy to participate.

Fantastic. If you're interested, you can get the current state of the project from the `sha256-interop` branch at https://github.com/bk2204/git.git. This is frequently rebased, but mostly to squash down patches or add new features. It is based on v7 of Patrick Steinhardt's Rust series and will effectively require `WITH_RUST=1` to function.

One really valuable thing that you could work on if you like is a tool to do in-place migration of repositories to add a compatibility algorithm, so SHA-1 repositories would have SHA-256 compatibility added on top. That might look like this:

* Recursively convert submodules, if any.
* Build a loose object map for any submodule commits that exist in the
  history.
* Repack all the loose objects into a pack (including using a cruft pack
  if necessary).
* Regenerate the indexes for the pack using pack index v3.

This might be a good subcommand for something like a `git hash` command, maybe `git hash convert`. We'd probably want to anticipate maybe in the future having a mode that converts the main algorithm, too, although that need not be implemented now.

You should be able to test this end-to-end with Git's repository, since it has submodules.

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