Re: When should we release Git 3.0?

[Taylor Blau <me@ttaylorr.com>]

On Tue, Sep 30, 2025 at 11:07:42PM +0000, brian m. carlson wrote:
> 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.

> * 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