RE: When should we release Git 3.0?

[<rsbecker@nexbridge.com>]

On October 7, 2025 6:27 AM, Patrick Steinhardt wrote:
>On Thu, Oct 02, 2025 at 12:54:13PM -0400, Ben Knoble wrote:
>>
>> > Le 2 oct. 2025 à 09:33, Patrick Steinhardt <ps@pks.im> a écrit :
>> >
>> > On Wed, Oct 01, 2025 at 12:04:38PM -0400, Taylor Blau wrote:
>> >>
>> >>
>> >> So my feeling here is that we should take into account not just the
>> >> readiness of the underlying Git implementation used by hosting
>> >> providers in the Git ecosystem, but also the readiness of the
>> >> hosting providers themselves to do the work necessary to facilitate
>> >> that transition outside of their Git implementation.
>> >
>> > We definitely should take into account the readiness. But what I
>> > think we'll need is a roadmap from impacted Git implementations and
>> > hosting providers so that we can answer the question when they plan
>> > to have
>> > SHA256 support ready.
>> >
>> > Without such a roadmap it's basically impossible for us to set up
>> > any realistic date. In that case, we only have one of two options:
>> >
>> >  - We just wait until eventually everyone has SHA256 support. This has
>> >    the effect that there is no pressure on anybody, and thus it is more
>> >    likely than not that it'll just never happen.
>> >
>> >  - We set a strict, "uninformed" deadline that may be too ambitious and
>> >    unrealistic.
>>
>> This seems like a false dichotomy to me. Of course we can forever
>> debate options to go forward, too, so at some point we must have a
>> decision :)
>>
>> Anyway, what about establishing a strong but adjustable (“proposed”)
>> timeline now, based on informed opinions from folks who have already
>> provided estimates of what’s required? Then we can shop around for
>> input on the proposed deadline while still taking into account new
>> information.
>>
>> It also provides impetus: “sans input, we will go forward with the
>> proposal, so let us know if you need more time” might motivate folks
>> to firm up their own timelines and provide said input.
>
>Yeah, it's definitely my goal here to do exactly that: reach out to folks and take
>everyone's input into account. Once we've got it, propose a timeline.

My own blocking situation is a lack of Rust. This is being discussed by the OS
vendor and I hope we get some progress soon. I do not control what "soon" is
but it is at least a year. This is HPE NonStop.

>I guess as part of that initial communication with the stakeholders we can also
>mention that the current plan is to release roughly towards the end of next year,
>which may help to put things into perspective.
>
>> > Once we have roadmaps, we should set a strict deadline that takes
>> > them into account. Any hosting provider or implementation of Git
>> > that doesn't provide a roadmap will not be taken into account in our planning.
>>
>> Btw, I’ve often wondered since I see representatives from
>> GitHub/GitLab (and JGit/Gerrit to a lesser extent) often prominently
>> identified as such: do we have folks from GitTea/SourceHut/other
>> smaller forges around on the mailing list to weigh in? I assume we’d
>> also like to include their input.
>
>Such smaller forges should definitely be included. My plan is to gather a list of
>stakeholders for now and then send an email where we Cc maintainers of such
>implementations.

My own front-end implementation has been ready for SHA-256 for 2 years and
have been (im)patiently waiting. I have a distinct separation between git version
and implementation so there is no direct dependency there. Only Rust availability
on the git built is holding my own situation back.
--Randall