RE: When should we release Git 3.0?
- From
rsbecker@nexbridge.com <rsbecker@nexbridge.com>
- Date
- Oct 7, 2025, 17:36 UTC
- Message-ID
- <00ff01dc37b0$e5bfb430$b13f1c90$@nexbridge.com>
- In-Reply-To
- <aOTrBAXhKF4iYzQB@pks.im>
On October 7, 2025 6:27 AM, Patrick Steinhardt wrote:
Show 45 quoted lines
>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.
Show 17 quoted lines
>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