Git 3.0's upcoming SHA-256 default will be a costly mistake
The author opens by saying he has been sitting on this topic for a few years, mostly because smarter people were already concentrating on it and he dislikes back-seat driving. His argument now is that the Git 3.0 release is about to cost everyone a lot of time and angst for little benefit, and that virtually nobody knows what is coming.
He then lays out the basics: Git is a content-addressable database, meaning it computes a hash of any content it stores or transmits and uses that hash as the key in a key/value store where the value is the content — the same content always gets the same hash, globally. This is useful because the same file content is never stored twice. It also produces a property where each commit encodes the hash of its parent commit, so integrity propagates: you cannot change the hash of anything without changing the hash of everything that comes after it. That gives Git "cryptographic integrity," where hashing the latest commit effectively hashes potentially millions of file contents, trees, and commits that came before it.
Git's hash function has always been SHA-1, chosen by Linus in 2005, and it has worked well for 20 years: relatively fast, and in a practical sense impossible for two different files to accidentally hash to the same value. As far as the author is aware, that has never happened in the history of every file, tree, and commit ever made in every Git repository ever created — billions and billions of them. Mathematically, for SHA-1's 160-bit output, the birthday bound means roughly 1.4 septillion random files would be needed in a single project for an accidental collision (1.4 quadrillion billion files, a number the author calls impossible to effectively describe).
The problem is that SHA-1 is now considered mathematically semi-"broken": published collision attacks (SHAttered in 2017, "SHA-1 is a Shambles" in 2020) exist, though they are not practical to exploit in any demonstrated way and are only theoretically possible. In response, after a huge amount of work by very smart people, Git 3.0 plans to change its default hashing algorithm from SHA-1 to the stronger SHA-256. The author pauses there to ask what "broken" actually means, noting it is probably not what normal people would think — from a cryptographic hashing standpoint, he begins to explain, broken essentially means that finding... (the excerpt cuts off mid-sentence), setting up his case that the severity of the flaw is being overstated relative to the cost of the migration.