From: Patrick Steinhardt <ps@pks.im>
To: "Michal Suchánek" <msuchanek@suse.de>
Cc: Junio C Hamano <gitster@pobox.com>, Taylor Blau <me@ttaylorr.com>,
Luca Milanesio <luca.milanesio@gmail.com>,
git@vger.kernel.org
Subject: Re: When should we release Git 3.0?
Date: Tue, 7 Oct 2025 12:27:23 +0200 [thread overview]
Message-ID: <aOTrC8CRZm5hERgr@pks.im> (raw)
In-Reply-To: <aN6j7giOosGreKUW@kitsune.suse.cz>
On Thu, Oct 02, 2025 at 06:10:22PM +0200, Michal Suchánek wrote:
> On Thu, Oct 02, 2025 at 08:32:38AM -0700, Junio C Hamano wrote:
> > Patrick Steinhardt <ps@pks.im> writes:
> >
> > > 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.
> >
> > Works fine as long as we assume everybody that matters will
> > eventually want to move away from SHA-1.
> >
> > - If a stakeholder gives a roadmap that has no SHA-256 in their
> > future, in other words, if they are content to serve only the
> > SHA-1 projects, what's the impact to them? We are not dropping
> > the support for SHA-1 in the sense that if you clone from an
> > existing SHA-1 repository you'll get an SHA-1 repository and you
> > can push and fetch between them just fine, so presumably that is
> > fine as well.
> >
> > - If a stakeholder gives a roadmap with SHA-256 so far into the
> > future that we cannot wait, what's the impact to them? Their
> > customers that want SHA-256 earlier than they can supply could
> > move to other hosting or implementation, but not really. Both
>
> I suppose that's already the case to some extent. git does support
> sha256, some forges do as well, and some people want it to the point
> that they install such forge, and create the sha256 repositories
> although it is not the default.
>
> There is some tradeoff here. When it's nice to have but not required
> people will use it when convenient. When it's really required people
> will use even an obscure implementation to get the requested feature.
True. In any case, I think that for now we should just wait how such
roadmaps would look like and then discuss based on the findings.
The question of course is how to get such roadmaps. The easiest way to
do it is probably to gather a list of known projects that would be
impacted and just shoot maintainers or representatives of those an
email? From the top of my head, that would include:
- Implementations
- libgit2
- JGit
- Gitoxide
- go-git
- Forges
- GitHub
- GitLab
- Bitbucket
- Forgejo
- SourceHut
I probably missed some stakeholders here, so please help me fill in the
blanks.
> > hosting providers and Git implementations have components that
> > are move than Git that are hard to migrate, like issue trackers,
> > CI services, workflow tools, etc., that make their customers
> > captive audience [*].
> >
> > - If a stakeholder has a roadmap with SHA-256 in line with our
> > timeframe, do we still need to assess the impact to them, or as
> > long as we and they work hard to stick to the plan, we all will
> > be happy?
Well, the impact in that case would be negligible, I assume, so everyone
woudl be happy. If plans change then we can of course also adapt our own
timeline a bit, at least as long as they would give us a notification
well ahead of the scheduled flag day.
Patrick
next prev parent reply other threads:[~2025-10-07 10:27 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
2025-10-02 15:32 ` Junio C Hamano
2025-10-02 16:10 ` Michal Suchánek
2025-10-07 10:27 ` Patrick Steinhardt [this message]
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=aOTrC8CRZm5hERgr@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=luca.milanesio@gmail.com \
--cc=me@ttaylorr.com \
--cc=msuchanek@suse.de \
/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).