cat-file: The Object-Store Swiss Army Knife

git cat-file is the plumbing command for inspecting any object by SHA. Four flags cover the bulk of its use:

git cat-file -t <sha>   # print type
git cat-file -s <sha>   # print size in bytes
git cat-file -p <sha>   # pretty-print body
git cat-file -e <sha>   # exit 0 if exists, non-zero if missing

These map almost 1:1 onto the four fields we worked with in the previous lesson: type, size, body, existence.

Why -p is "pretty"

For a blob, -p just dumps the raw bytes — no transformation.

For a tree, -p un-binarifies the entries:

100644 blob b6fc4c620b67d95f953a5c1c1230aaab5db5a1b0    README.md
100644 blob 95d09f2b10159347eece71399a7e2e907ea3df4f    src/main.py
040000 tree 04df07b08ca746b3167d0f1d1514e2f39a52c16c    docs

Each entry is decoded into <mode> <type> <hex-sha> <name>. The raw on-disk format would be 20 binary SHA bytes — unprintable.

For a commit, -p outputs the textual body verbatim:

tree 9f2c8e5bf3a2b8c4d5e6f7a8b9c0d1e2f3a4b5c6
author Alice <[email protected]> 1716383442 -0500
committer Alice <[email protected]> 1716383442 -0500

Initial commit

(Commits and tags are already-textual; -p is a no-op decode.)

Why -e is special

-e is unique because it shouldn't error on a missing object — it intentionally exits non-zero with no output. Scripts use it as a cheap "does this SHA exist?" check:

if git cat-file -e abc1234^{commit}; then
    echo "abc1234 is a valid commit"
fi

That ^{commit} suffix forces a type assertion — useful when you want to confirm not just existence but type.

Implementation in 30 lines

Once you have the object store from the previous lesson, cat-file is a trivial dispatcher:

That's it. The complexity in real git comes from:

• Resolving short SHAs (abc1234 -> full 40-char)
• Following ref-style names (HEAD~3, main^{tree})
• Reading from packs, not just loose objects
• The --batch mode that processes many SHAs from stdin

But the core dispatch is exactly what you'll build.