- Git 3: two hash formats
+ Pi 1.0 + experimental Durable
+ SvelteKit 3 + migration TODOsYou'd think upgrading Git keeps your tools talking. Git's proposed SHA-256 default creates repositories that today's SHA-1 format can't talk to. Scott Chacon, a GitHub cofounder and Pro Git author, calls the transition a costly mistake. The Git project's plan makes ecosystem readiness a condition of changing the default.
What Git 3 would change
The planned default covers new repositories. The official document gives no release date, keeps SHA-1 supported and requires libraries, applications and hosting services to be ready. Your existing repository keeps its format when you upgrade the executable. Before the group chat schedules an emergency migration, the deadline is currently a blank calendar.
Git names objects by hashing their contents. Trees refer to files and other trees; commits refer to trees and earlier commits. Changing the hash algorithm changes the names and the references embedded in those objects. A migration needs a mapping between the two sets of identities.
Chacon reaches back to Git creator Linus Torvalds's 2005 argument for trusted distribution. The security case has moved since then: researchers demonstrated SHA-1 collisions in 2017 and later a chosen-prefix attack against PGP identity certificates. Modern Git uses hardened SHA-1 to detect known collision attacks. Its maintainers also want protection against future attacks.
Chacon thinks the ecosystem bill buys too little security. He proposes signing a separate strong checksum of tree contents while keeping today's object addressing. That is his alternative proposal. Git's published transition design instead describes mapping object identities and handling signatures across the formats.
The compatibility check
I created disposable local repositories in both formats and hashed the same little file. SHA-1 produced a 40-character object name; SHA-256 produced 64 characters. Fetching between the formats with the installed Git 2.34.1 returned fatal: mismatched algorithms: client sha256; server sha1, matching the current official manual's interoperability warning. This demonstrates today's boundary; Git 3 remains unreleased.
The migration work reaches scripts that assume a hash's length, object links and embedded Git libraries. A design document doesn't upgrade the library hiding in your favorite developer tool. Test your host and toolchain before choosing SHA-256 for a project. Existing teams can keep their current format while the ecosystem catches up.
Pi 1.0 and crash recovery
Earendil released Pi 1.0, a minimal coding-agent harness with native MCP support through Codemode and deferred tool loading. If your agent setup already resembles a small government, keeping tools out of the prompt until needed sounds like administrative reform.
The separate experimental Pi Durable framework checkpoints tasks in persistent storage. A tool interrupted by a crash reruns only when it declares replay safe; otherwise the model gets told it was interrupted. That boundary matters when a tool can spend money. I want the assistant to remember my shopping list without celebrating a crash by buying it twice.
SvelteKit 3's migration homework
SvelteKit 3 moves configuration to vite.config.ts and replaces $lib with #lib through standard package subpath imports. The official migration command automates what it can and leaves a to-do list for the rest. The announcement even recruits your robot friends for the leftovers: a framework upgrade ships homework and a suggested substitute teacher.
Remote functions still require experimental Async Svelte. A major version number feels reassuring, but individual features carry their own maturity labels. Check the ones you're using.
GitHub's working exception
Brian Carlson's public talk repository already returns a full SHA-256 object name. I checked its public remote directly. The published slides label GitHub support private preview and say repository creation is still coming.
That proves GitHub can serve this preview repository. Ordinary project creation, write access and your integrations still need their own checks. There's actual progress behind the waiting room.
Verdict: NEEDS REVIEW — Test the whole toolchain
I'd keep the stronger hash option and test the whole toolchain before changing defaults. Compatibility is part of shipping the security improvement.
Sources
https://git-scm.com/docs/BreakingChanges#_git_3_0
https://blog.gitbutler.com/git-3-sha-256
https://news.ycombinator.com/item?id=49924179
https://git-scm.com/docs/git-init
https://git-scm.com/docs/hash-function-transition
https://sha-mbles.github.io/
https://github.com/schacon/tree-sha256
https://github.com/orgs/community/discussions/12490#discussioncomment-18539601
https://github.com/bk2204/talk-rust-in-git
https://earendil.com/posts/pi-1-0/
https://earendil.com/posts/pi-durable/
https://svelte.dev/blog/sveltekit-3-is-here
https://svelte.dev/docs/kit/migrating-to-sveltekit-3
And that's the diff for today. I'm Niko from Axrisi. Merge responsibly.
YouTube · thedailydiff.dev · forward this to the intern who deployed on Friday.