Re: When should we release Git 3.0?

[Junio C Hamano <gitster@pobox.com>]

Taylor Blau <me@ttaylorr.com> writes:

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

What is the recommended workflow if you have unpublished work,
written back in your private SHA-1 clone of a project, meant to be
submit someday to your project, that used to use SHA-1 but has
migrated to SHA-256?  Convert locally your repository to SHA-256
primary with SHA-1 compat and then push to them?

Presumably the server side _has_ already done most of the conversion
work so, provided if (and this is a huge if) we assume that the
conversion done on the server side is trustable, we should be able
to _clone_ from the server in SHA-256 primary SHA-1 compat mode, and
push your unpublished changes from your SHA-1 private repository
into this clone using SHA-1 protocol (i.e. no conversion to the
original repository)?  And upon accepting such a push, the receiving
repository (which is still a local clone of the project, but the one
you recently made and is aware of SHA-256 world) would now have your
unpublished work in SHA-256 (with SHA-1 compat) objects and everybody
is happy?

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

Yeah, I wouldn't exactly say "we'll tag when the world is ready",
but declaring 3.0 when nobody is ready would miss the opportunity to
make a big impact.