Inspecting Git Objects in Practice

An Object ID gives Git a way to retrieve a stored object. In this lesson, we follow a real snapshot from a Commit to a file’s bytes. Run the examples in a disposable training repository; your IDs and file names will differ.

The path through a snapshot

Commit → Root Tree → App Tree → user.php Blob → file content

A Commit records a Root Tree ID. A Tree records names, modes, and child Object IDs. A Blob stores file content without a filename. Reading each object makes those relationships visible.

Read the current Commit

git cat-file inspects stored objects without changing the Working Tree, Index, or history:

git cat-file -t HEAD
git cat-file -p HEAD

-t prints the object’s type; the first command normally prints commit. -p presents its contents in a readable form:

tree <root-tree-id>
parent <previous-commit-id>
author ...
committer ...

Commit message

HEAD resolves to the current Commit here. The tree line identifies its project snapshot, while parent links to the previous Commit. A root Commit has no parent line.

Follow the Trees

Copy the ID from the tree line and inspect it:

git cat-file -t <root-tree-id>
git cat-file -p <root-tree-id>

The type is tree. Its readable output contains entries like:

100644 blob <blob-id>  app.txt
040000 tree <tree-id>  App

The entry for App points to another Tree. Inspect that ID to find its entries:

git cat-file -p <app-tree-id>

For example, it may contain 100644 blob <blob-id> user.php. The Tree supplies user.php; the Blob supplies its bytes:

git cat-file -t <user-blob-id>
git cat-file -p <user-blob-id>

The first command prints blob; the second prints the file content recorded under that ID. Passing that same ID later still reads that same content, even if the Working Tree file has since changed. Two differently named Tree entries may point to one Blob when their content bytes match.

What does -s measure?

git cat-file -s <user-blob-id>

-s prints the size of the object’s uncompressed content in bytes. It is not the on-disk size of a compressed loose object or a packfile entry. In our training repository, the inspected user.php Blob was 105 bytes.

Calculate an ID or store a Blob

git hash-object <path> calculates the Blob ID from a Working Tree file without writing an object. Adding -w stores the Blob:

git hash-object object-lab.txt
git hash-object -w object-lab.txt

The Object ID depends on the exact bytes, the object type and header, and the repository’s object format. A content edit changes the calculated ID. Saving a file without changing its bytes does not.

-w does not stage the file or create a Commit. In our disposable repository, hash-object -w object-lab.txt returned a Blob ID, and git cat-file -t/-p confirmed that the stored object was a Blob containing dddd. Meanwhile, git status --short still showed:

?? object-lab.txt

The Index had no entry connecting the pathname to the Blob. Ordinary git add both stores the content when needed and updates the Index; git commit writes Trees from the Index and creates the Commit.

An object stored only with hash-object -w is not a substitute for a Commit or a work-saving workflow. A Blob alone does not remember its filename or path. Do not rely on an unreferenced object remaining available indefinitely.

Storage note

Git may store objects separately as loose objects or together in packfiles. Their storage layout does not change what git cat-file returns. Packfile mechanics and cleanup belong to a later lesson.

Common mistakes

• Reading -s as compressed disk usage.
• Assuming hash-object -w performs git add or git commit.
• Expecting a Blob ID to reveal the original filename.
• Expecting a fixed Blob ID to show newer Working Tree edits.
• Treating a manually stored, unreferenced Blob as a reliable backup.

Summary

Use cat-file -t for type, -p for readable content, and -s for uncompressed content size. Follow a Commit’s Root Tree through nested Trees to a Blob. Plain hash-object computes an ID; hash-object -w also stores a Blob, but neither form stages or commits a file.

Knowledge check

What identifies a file’s path in a snapshot?

Tree entries provide names and links to child objects. A Blob provides content only.

Why can cat-file -p still read an older version after a Working Tree edit?

An exact Blob ID names the original immutable object. The edit changes Working Tree bytes, not that stored object.