Git 3.0's upcoming SHA-256 default will be a costly mistake

Git 3.0 plans to switch Git’s default content hash from SHA-1 to SHA-256, replacing the 20-year-old SHA-1 that underpins Git’s content-addressable object database. SHA-1 produces a 160-bit identifier used as a key for every blob, tree and commit, which gives Git its chaining integrity: changing any object changes all descendant hashes. SHA-1 has known collision attacks (e.g., SHAttered), meaning attackers can deliberately craft two different files with the same hash, and some collisions have been demonstrated at non-astronomical cost for specific content shapes. Accidental collisions, however, remain effectively impossible given the birthday bound (on the order of 1.4×10^24 objects in a single project), and second-preimage attacks (creating an alternative file to match an existing hash) remain computationally infeasible in practice.

Mandating SHA-256 as the default is argued to be an enormous, unnecessary global migration cost for marginal practical benefit. Real-world compromises typically occur through social engineering, compromised maintainers, or insecure package forges - not via expensive, targeted hash collisions - because trust in SCM is primarily about where code is pulled from, repository provenance and distribution channels rather than hash choice. Stronger mitigations (repository authentication, signatures, supply-chain security) address real threats more directly, while the SHA-256 switch imposes widespread compatibility and operational burdens with little measurable increase in defenses against realistic attacks.