One team's half-day audit found seven places its tooling assumed a 40-character Git hash

`git init --object-format=sha256` creates the test repo. After one commit, `git rev-parse HEAD | wc -c` returns 65, which is a 64-character hash plus a newline ^[7][9]. The repo records its format in config, where `git config extensions.objectFormat` prints `sha256` ^[21]. The author recommends Git 2.42 or later for this, though the flag dates to Git 2.29 in 2020 ^[19][3]. The post calls the new hash about one and a half times the usual length ^[10]. It is 1.6 times. That is close enough in conversation and wrong for a fixed-width column ^[1].

The author's fastest test is to copy that repo into the pipeline and run the pre-commit hooks, release scripts and changelog tools against it ^[18]. The static search looks for five shapes: a `[0-9a-f]{40}` regex, a `len(sha) == 40` or `sha.length === 40` check, a `CHAR(40)` or `VARCHAR(40)` column, the `'0' * 40` null hash in `pre-receive` hooks, and `line[:40]` slicing of `git log --format=raw` output ^[12]. A short bash script runs them through ripgrep 14.x over the monorepo, the Terraform and Ansible repo, and the CI config repos ^[13].

The search took about half a day and turned up seven hits ^[2]. Two were regexes in a release-note tool. One was a `CHAR(40)` column in the `deployments` table, and one was a `pre-receive` hook comparing against forty zeros ^[14]. The other three were input validation in an internal API ^[2]. Another team should expect a similar count only if its commit IDs pass through the same kinds of code: release tooling, deploy records, hooks and validators. I'd expect a shop with more services that store hashes to find more.

The author warns against swapping `{40}` for `{64}`. That just moves the bug to SHA-1 repos, and the transition may last years with both formats in use ^[15]. The shared Python helper gets this right. It accepts a full hash only at exactly 40 or 64 hex characters. It builds the hook's null hash as zeros times the length for the repo's format, which it reads from `git rev-parse --show-object-format` ^[16]. That command is also the author's general rule: ask Git for the format instead of inferring it from string length ^[11]. Each fix is then tested against a SHA-256 repo ^[17].

The author's view is that the breakage usually sits in CI scripts, regexes, database schemas and internal tools, and not in Git ^[20]. The audit supports that for code a team owns. The Git 3.0 default reaches the post through a Hacker News article, and the post does not give a release date ^[1].