Git's SHA-256 Default Under Breaking-Changes Builds, Not Just After 3.0 Ships, Will Still Break CI Scripts

A SHA-256 object ID is 64 hex characters where SHA-1 used 40 ^[6]. At four bits per hex digit, that is 256 bits against 160 ^[1]. Any code that checks or extracts a commit hash by length is affected. A regex anchored to exactly 40 characters rejects the new IDs outright. Without the end anchor, it matches the first 40 characters, and a script that extracts the match passes a truncated ID to the next step with no error raised ^[2].

The BreakingChanges document sets the scope: the new default applies to newly initialized repositories ^[1]. Existing SHA-1 repositories are not converted, and the document says there is "no plan to deprecate the sha1 object format at this point in time" ^[2]. A script that only touches existing repositories keeps seeing 40 characters. Exposure starts when someone runs `git init` on 3.0, or picks SHA-256 when a forge asks for a format at creation ^[17]. To see which format a repository uses, run `git rev-parse --show-object-format` ^[4].

According to the post, Chacon co-wrote Pro Git and founded GitHub and GitButler ^[8]. He calls the switch a "global train wreck" that buys almost no real security ^[10]. He accepts that SHA-1 collisions are real. SHAttered produced one in 2017, and the 2020 "SHA-1 is a Shambles" paper brought chosen-prefix collisions down to about 2^63 operations ^[12]. His objection is to what that buys an attacker inside Git. The attacker has to manufacture two variants that hash identically, get a victim who has never pulled before to fetch the malicious one, and get it run ^[13]. He puts the practical chosen-prefix cost at "a few tens of thousands of dollars" for contrived content ^[13]. Buying out a burned-out maintainer for a $40k lump sum, he wrote, is "maybe a billion times simpler, cheaper and more likely to succeed" than a cryptographic attack ^[14].

That argument is about benefit. Neither camp disputes the length change ^[6]. Chacon's own list of casualties covers every script, CI pipeline, issue tracker and deploy tool that assumes a 40-character hash, and he calls it long, wide-ranging and largely unsolved, with no consensus fix ^[18]. I think that list is the most useful part of his post for anyone who owns tooling, whichever way the default argument ends. The deadline depends on the hosts. According to Hacker News commenters cited in the post, GitHub's SHA-256 hosting is in private beta ^[16].

The field evidence is thin. The post's author says he has not run the official migration tooling in production and works from Chacon's post, the Git documentation and the HN thread ^[19]. His opening story has a team moving a legacy service from Bitbucket Server to GitHub and finding that half its CI scripts parsed commit hashes with a 40-character regex, while the new hashes were 64 characters ^[7]. The post does not explain where 64-character hashes came from, given the GitHub hosting gap Chacon describes ^[15]. Finding every affected spot took a full day ^[7].