Git Object ID (hash-object)

Because git hashes a header first. The input to the hash is the object type, a space, the length of the body in bytes, a zero byte, and then the body, so sha1sum of the same file is a different number entirely. Prepend the header yourself — printf 'blob 11\0hello world' | sha1sum — and it matches.

No. A blob is contents and nothing else, which is why a repository with the same file in twenty places stores one object and why renaming a file does not create a new blob. Names, modes and the directory structure live in tree objects, and those trees are what a commit points at. If two files in your project have the same id, they are byte-identical.

Almost always line endings. With core.autocrlf true on Windows, or a text attribute in .gitattributes, git converts CRLF to LF on the way in, so the blob it stores is not the bytes on your disk. Other clean filters — a smudge/clean pair, or the ident attribute — have the same effect. Hashing the file here gives the id of the file as it exists; git rev-parse HEAD:path gives the id of what was stored.

git init --object-format=sha256 makes a repository that names objects by SHA-256 of the same header-plus-body input, and prints 64-character ids. Nothing else about the rule changes, which is why both ids appear here. The two id spaces do not interoperate, so an id from a SHA-1 repository cannot be translated; a conversion means rewriting the objects.

SHA-1 collisions have been constructed since 2017, and git's answer was to switch its internal hash to a hardened variant that detects the known attack pattern and refuses the input rather than to change every id. For any ordinary file the hardened function and plain SHA-1 agree, which is why the value here matches git's — the difference only shows on a crafted collision pair. Repositories that want a real margin use the SHA-256 object format.