The plan is real. The date is not.
Git's breaking-change document says Git 3.0 will change the default hash for newly created repositories from SHA-1 to SHA-256. It also says there is no planned Git 3.0 release date. The same document calls itself a living record and says earlier decisions can be revisited.[1]
That is enough reason to test. It is not a reason to tell teams that every repository is about to change. Existing repositories keep their format. New repositories get the new default unless the final plan changes or an operator chooses a format.
The decision worth making today is not which side wins the argument. It is whether your tools know the repository format they are operating on.
Object format reaches inside the objects.
Git's transition design says SHA-256 repositories use a repository-format extension. The change affects object names and the object content that refers to other objects. Older Git versions cannot read those repositories. The design proposes a bidirectional mapping between SHA-1 and SHA-256 names for transition work.[2]
Do not reduce this to widening a database column from 40 to 64 characters. Search for validators, regular expressions, cache keys, URL routes, webhook fields, artifact names, signatures, fixture snapshots, abbreviated IDs, and systems that copy an object ID into another store.
Current documentation still marks an exchange gap.
The current git init documentation accepts --object-format=<format>. It warns that SHA-256 repositories and SHA-1 repositories do not interoperate at present. It also documents init.defaultObjectFormat, which means teams can test their own creation path before a major release changes the default.[3]
On this dispatch host, Git 2.43 created both formats. The SHA-1 commit ID had 40 hexadecimal characters and the SHA-256 commit ID had 64. A local fetch from the SHA-1 repository into the SHA-256 repository stopped with mismatched algorithms: client sha256; server sha1. That is one local smoke check, not a forecast for Git 3.0.
The cost argument deserves a test matrix.
Scott Chacon argues that changing the default will impose broad costs while adding little practical security value. His case covers collision attacks, forge support, signatures, dependency references, storage, protocol translation, and the long tail of tools built around SHA-1 object IDs.[4]
The official Git design starts from a different risk judgment. It points to practical SHA-1 collision work, hardened SHA-1 as a mitigation rather than a permanent answer, and the need for object names that remain trustworthy.[2] Do not erase that disagreement with a slogan. Convert each claimed cost and benefit into a fixture your tool can run.
Keep human names above object names.
Object IDs leak into tickets, deployment records, package locks, submodule entries, status pages, and chat. Prefer a branch, tag, release, or repository URL when that is the durable identity you mean. When an exact object is required, store the algorithm beside the full ID.
That will not make incompatible repositories exchange objects. It will stop your own records from silently assuming that every identifier is SHA-1 forever.