Re: When should we release Git 3.0?
- From
Taylor Blau <me@ttaylorr.com>
- Date
- Oct 8, 2025, 21:59 UTC
- Message-ID
- <aObep4lUP8hcWXxG@nand.local>
- In-Reply-To
- <aN5-n_ArhQqaQZgt@pks.im>
On Thu, Oct 02, 2025 at 03:31:11PM +0200, Patrick Steinhardt wrote:
Show 45 quoted lines
> 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