What changes when a Git repository is created with --object-format=sha256?

## What the flag does `git init --object-format=sha256` creates a repository whose object database is named with SHA-256 instead of SHA-1. Two things are recorded in the local config: `core.repositoryformatversion = 1` and `extensions.objectFormat = sha256`. The version bump matters — a Git that does not recognise an extension it finds in a version-1 repository refuses to operate on it, which is far better than misreading it. The choice is made at creation and applies to the whole repository; there is no per-branch or per-object mixing. ## What visibly changes Object ids grow from 40 hex characters to 64. Everything that carries an id widens with them: tree entries, the `tree` and `parent` lines of commits, the `object` line of tag objects, ref files, the reflog, the index. Hashing still follows the same recipe — a header of type and byte length, a NUL, then the content — so the same file yields a valid but entirely different id under the new algorithm. ## Why conversion is hard This is the part interviewers are testing. Git's data structure is a Merkle graph: a tree names its blobs by hash, a commit names its tree and parents by hash, a tag names its target by hash. Rehashing one object changes its id, which changes every object that referenced it, all the way to the branch tips. So converting a repository is not a re-index; it is a full rewrite in which every id in existence changes, and every id that lives *outside* the object graph — in commit messages, issue trackers, build logs, deployment records, signed artefacts, other people's clones — no longer resolves. Interoperability between the two formats is not implemented, so a SHA-256 repository and a SHA-1 repository cannot exchange history directly. ## Why the sky has not fallen for SHA-1 Git's use of SHA-1 was never a signature scheme by itself, and a practical attack would require producing a colliding object that is also plausible content an unsuspecting maintainer accepts. Recent Git versions additionally hash with a collision-detecting SHA-1 implementation that recognises the byte patterns produced by the known collision technique and aborts rather than writing the object. That is a mitigation, not a fix, which is exactly why the SHA-256 format exists as the long-term path. ## What to say in an interview Make three points: the format is repository-wide and declared through a config extension so old clients fail loudly; the hash is embedded transitively in every object, so migration means rewriting the entire graph and invalidating every id anyone has ever written down; and the SHA-1 story is mitigated in the meantime by collision detection. Do not claim a specific hosting provider or tool supports the format — the honest answer is that ecosystem support, not Git's own implementation, is the limiting factor.