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