Re: When should we release Git 3.0?

From: Taylor Blau <me@ttaylorr.com>
Date: Oct 1, 2025, 16:01 UTC
Message-ID: <aN1QUDzYli0GsGy9@nand.local>
In-Reply-To: <aNxivuJEnSHbQNdr@fruit.crustytoothpaste.net>

On Tue, Sep 30, 2025 at 11:07:42PM +0000, brian m. carlson wrote:

Show 9 quoted lines

> Almost all of the functionality that we had wanted in Git 3.0 has been
> implemented.  The two major things we may want to consider as blockers
> for Git 3.0 are the following:
>
> * The SHA-256 interoperability work is not done yet.  My estimate of
>   this work is 200–400 patches, of which about 100 are done.  If the
>   original schedule is maintained, this would require writing up to 75
>   patches and sending in 100 patches per cycle, which is unrealistic
>   without additional contributors.

I need to polish up the notes from the Contributor's Summit and share them with the list, but my general feeling at the end of the discussion on the SHA-256 interoperability work was that it wasn't clear whether or not it should be a blocker for Git 3.0.

If post-3.0 repositories are using SHA-256, then either their post-Git 3.0 clients will also use SHA-256, or the pre-3.0 clients (without interop support) will be unable to interact with them. I don't think there would be any reason to have a interop-capable client use a SHA-256 repository in SHA-1 mode.

On the other side of the coin, if a repository is still using SHA-1, then both pre-3.0 and post-3.0 clients will be able to interact with it without interop support.

But you have thought about the interop work far more than I (or anybody else) has, so I am very likely missing some obvious use-case here.

Show 12 quoted lines

> * Some forges and other projects do not yet have full SHA-256 support.
>   It's my understanding that all of the major forges are undertaking or
>   have undertaken this work and are at various levels of completion, but
>   it's not clear that other projects have appropriate support.
>
> We may also wish to stick to a stricter timeframe for this release
> regardless and make four releases from now or the next release a year
> away Git 3.0 regardless of whether those items above are completed.
>
> Discussions at the Contributor Summit did mention the advantage of
> having a hard deadline would be that it would make projects and forges
> spend the time to implement SHA-256 support if they're lacking it.

My feeling on this portion of the discussion was that we should take into account the readiness of the ecosystem as a whole in deciding when to release Git 3.0.

I agree that not having a deadline can lead to forges delaying the work necessary to support SHA-256 repositories, so I agree that we shouldn't push it off into the future indefinitely.

On the other side of the coin, I don't think we should rush Git 3.0 out the door before the ecosystem is broadly ready for it. If we do that, we're creating a worse experience for a significant portion of Git users that use popular forges who may not have complete SHA-256 support at the time of the release.

Thanks, Taylor