Git 3.0's upcoming SHA-256 default will be a costly mistake
- ID
- 31055
- Status
- summarized
- Published
- 02 Oct 2026, 12:57 AM
- Fetched
- 02 Oct 2026, 3:20 PM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://blog.gitbutler.com/git-3-sha-256
- Source URL
- https://hnrss.org/best
Summary
- Score
- 7.0
- Created
- 02 Oct 2026, 3:21 PM
- Tags
- Audience
- developersvibe_coderssaas_founders
What happened
Scott Chacon argues that Git 3.0's plan to make SHA-256 the default content-hashing algorithm is an expensive, low-value global migration. The piece recounts that Git has used SHA-1 since Linus picked it in 2005, that accidental collisions would require roughly 1.4 septillion files in one project, and that the only real weakness is theoretical collision attacks published as SHAttered (2017) and 'SHA-1 is a Shambles' (2020). The Hacker News thread drew 324 points and 312 comments.
Why it matters
Anything you run that assumes a 40-character SHA-1 hex object ID — build cache keys, CI fingerprints, hooks, scripts, or a database column storing commit hashes — is what this default change would break, and Git 3.0 timing means you should decide now whether to pin/opt out or budget for a migration. Note the excerpt argues the cost is huge but does not quantify it; the specific migration mechanics and the article's supporting numbers beyond the 1.4-septillion collision figure are not in the text provided, so treat the cost claim as an argument to evaluate, not a measurement.
Discussion angle
Should SHA-256 be a default or stay opt-in — and which of your own tools, caches, or DB schemas hardcode 40-character commit IDs today?