From: Patrick Steinhardt <ps@pks.im>
To: Taylor Blau <me@ttaylorr.com>
Cc: Luca Milanesio <luca.milanesio@gmail.com>, git@vger.kernel.org
Subject: Re: When should we release Git 3.0?
Date: Thu, 2 Oct 2025 15:31:11 +0200 [thread overview]
Message-ID: <aN5-n_ArhQqaQZgt@pks.im> (raw)
In-Reply-To: <aN1RFvz7uGPnepxe@nand.local>
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.
We should of course actively reach out to the projects that we're aware
of so that they have a chance to provide such a roadmap in the first
place.
Patrick
next prev parent reply other threads:[~2025-10-02 13:31 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-30 23:07 When should we release Git 3.0? brian m. carlson
2025-10-01 7:13 ` Luca Milanesio
2025-10-01 16:04 ` Taylor Blau
2025-10-01 19:31 ` rsbecker
2025-10-08 21:44 ` Taylor Blau
2025-10-08 21:55 ` rsbecker
2025-10-02 13:31 ` Patrick Steinhardt [this message]
2025-10-02 15:32 ` Junio C Hamano
2025-10-02 16:10 ` Michal Suchánek
2025-10-07 10:27 ` Patrick Steinhardt
2025-10-07 10:36 ` Michal Suchánek
2025-10-07 13:21 ` Patrick Steinhardt
2025-10-07 13:40 ` Michal Suchánek
2025-10-07 17:11 ` Junio C Hamano
2025-10-07 17:28 ` Michal Suchánek
2025-10-08 20:44 ` SZEDER Gábor
2025-10-09 5:56 ` Patrick Steinhardt
2025-10-02 16:54 ` Ben Knoble
2025-10-07 10:27 ` Patrick Steinhardt
2025-10-07 17:36 ` rsbecker
2025-10-08 22:05 ` Taylor Blau
2025-10-09 5:59 ` Patrick Steinhardt
2025-10-16 21:32 ` brian m. carlson
2025-10-08 21:59 ` Taylor Blau
2025-10-16 21:42 ` brian m. carlson
2025-10-02 22:33 ` brian m. carlson
2025-10-01 16:01 ` Taylor Blau
2025-10-01 16:20 ` Michal Suchánek
2025-10-01 22:16 ` brian m. carlson
2025-10-02 12:13 ` Michal Suchánek
2025-10-02 13:09 ` Michal Suchánek
2025-10-01 20:36 ` Junio C Hamano
2025-10-01 22:42 ` brian m. carlson
-- strict thread matches above, loose matches on Subject: below --
2025-10-08 19:06 James Frost
2025-10-09 5:30 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aN5-n_ArhQqaQZgt@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=luca.milanesio@gmail.com \
--cc=me@ttaylorr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).