From: Taylor Blau <me@ttaylorr.com>
To: git@vger.kernel.org
Subject: [NOTES 09/11] Git 3.0
Date: Mon, 6 Oct 2025 15:20:27 -0400 [thread overview]
Message-ID: <aOQWewStCoT10jDf@nand.local> (raw)
In-Reply-To: <aOQVeVYY6zadPjln@nand.local>
Topic: Git 3.0
Leader: Patrick Steinhardt
* Any questions?
* Emily: Patrick, you had proposed the end of next year as the cut date, are
people happy with that?
* Taylor: we've been using that internally as a benchmark for when we need to
deliver SHA-256. If Git 3.0 came later and we had more time, certainly
wouldn't complain, but also wouldn't ask the project to push it back purely on
that basis.
* Caleb: we need community support for SHA-256.
* Emily: feels like everybody is playing chicken.
* Taylor: ultimately the users need to tell us.
* Patrick: is there work going on on GitOxide?
* Caleb: nobody is asking for it from GitButler's perspective
* Elijah: if we don't push a date out, nobody will ask for it.
* brian: the cost for creating a SHA-1 collision is roughly $10k USD. Don't want
to spend my bonus check on it, but could do it and spam us with alerts.
* Taylor: sure, but we could just silence those alerts. Also, who would spend
$10k on this? ;-)
* brian: fair, though not implementations are using a SHA1-DC?
* brian: we should include this in Git 3.0, and we should set a hard date for
it. We should plan the interop work around that, but can't guarantee that it
will land by then.
* Martin: what's in scope for Git 3.0?
* Elijah: SHA-256 (and maybe interop) is the main thing, some deprecations
* Patrick: we have a BreakingChanges that lists what we want to remove.
Default reference backend is going to become reftable.
* Taylor: we should be doing brown-outs for deprecated features
* Elijah: we should delay for interop
* Peff: how important is interop really? What is the use-case?
* Elijah: will forges actually support SHA-256 once we enable it? Do we have
people create SHA-256 and then have them not push them anywhere.
* Peff: how do we push forges versus not?
* Peff: When we release Git 3.0 should not depend on whether or not interop
works, but whether or not real-world forges and plugins support SHA-256
* brian: smaller forges aren't there yet and won't undertake it until it's in
3.0
* Taylor: sure, but not the vast majority of users. Ultimately there are always
going to be some stragglers. Reality is that what “we” consider to be Git and
the rest of the world consider to be Git are not the same thing. So if we
release without good support on the forges side, users will be mad at us.
* Let's figure it out on the list?
* brian: I'll start that off.
next prev parent reply other threads:[~2025-10-06 19:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-06 19:16 Notes from the Git Contributor's Summit, 2025 Taylor Blau
2025-10-06 19:18 ` [NOTES 01/11] SHA-256 and interoperability work Taylor Blau
2025-10-06 19:18 ` [NOTES 02/11] First-class conflicts in Git? Taylor Blau
2025-10-06 19:18 ` [NOTES 03/11] The future of history rewriting - rebase, replay and history (+Change-IDs) Taylor Blau
2025-10-06 19:18 ` [NOTES 04/11] Rust Taylor Blau
2025-10-06 19:19 ` [NOTES 05/11] Pluggable object databases Taylor Blau
2025-10-06 19:19 ` [NOTES 06/11] Repository maintenance long-term goals Taylor Blau
2025-10-06 19:19 ` [NOTES 07/11] Change-ID Header in Git Taylor Blau
2025-10-06 19:20 ` [NOTES 08/11] Resumable fetch / push Taylor Blau
2025-10-06 19:20 ` Taylor Blau [this message]
2025-10-06 19:20 ` [NOTES 10/11] How can companies respectfully engage contractors to work on Git? Taylor Blau
2025-10-06 19:20 ` [NOTES 11/11] Conservancy 2025 updates Taylor Blau
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=aOQWewStCoT10jDf@nand.local \
--to=me@ttaylorr.com \
--cc=git@vger.kernel.org \
/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).