Re: When should we release Git 3.0?

[Taylor Blau <me@ttaylorr.com>]

On Thu, Oct 02, 2025 at 03:31:11PM +0200, Patrick Steinhardt wrote:
> On Wed, Oct 01, 2025 at 12:04:38PM -0400, Taylor Blau wrote:
> > On Wed, Oct 01, 2025 at 08:13:12AM +0100, Luca Milanesio wrote:
> > > I am worried that if we rush into Git 3.0 with breaking changes that
> > > would make other “forges” (e.g. JGit) incompatible, we would be in a
> > > difficult situation with the other Git ecosystem that isn’t based on
> > > the C-Git implementation.
> >
> > That's a good point. I am not familiar enough with JGit (or really any
> > non-standard Git implementations) to know where SHA-256 support is in
> > those respective implementations.
> >
> > But regardless of whether we're talking about a forge that is based on
> > git.git or some other implementation, there is very likely lots of other
> > work to be done to support SHA-256 outside of flipping the hash function
> > within Git.
> >
> > (I'm thinking here about database migrations for columns that may store
> > 40-character SHA-1 hashes, for example, which can take a potentially
> > significant amount of time to migrate depending on the size of the
> > database, etc.)
> >
> > 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.
>
> 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.

I would imagine that the definition of "roadmap" here is fairly
lightweight, since I imagine that some organizations may not want to
share details beyond "we will have it done by X date".

I think I generally agree with you, but I would say that while I think
the project should take a firm stance on when it will release Git 3.0, I
do not think that we should entirely disregard the readiness of
forges/implementations by making the deadline so strict.

Thanks,
Taylor