On October 7, 2025 6:27 AM, Patrick Steinhardt wrote:

On Thu, Oct 02, 2025 at 12:54:13PM -0400, Ben Knoble wrote:

quoted

quoted

Le 2 oct. 2025 à 09:33, Patrick Steinhardt [off-list ref] a écrit :

On Wed, Oct 01, 2025 at 12:04:38PM -0400, Taylor Blau wrote:

quoted

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.

quoted

quoted

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