Git Object Model: Blobs, Trees, Commits, Tags, and the Object Database: Diagnostics, Failure Modes, Security, and Performance

1. Evidence-first object diagnostics

1. Preserve evidence: exact name/OID, command, error, Git version, repository path.
2. Inspect refs/history: status, show-ref, log, rev-parse.
3. Inspect objects through Git: cat-file, ls-tree, fsck when integrity/connectivity is genuinely in question.
4. Identify the layer: working-tree path, tree entry, blob, commit, tag, ref, or physical storage.
5. Choose the least destructive correction and verify again.

Most object-model confusion is solved by asking Git what a name resolves to. Manual editing of .git/objects is not a diagnostic shortcut.

2. Failure mode — treating a filename as blob identity

Create one commit with the same content under two names:

git rev-parse HEAD:path/to/file
git ls-tree -r HEAD -- path/to/file

A tree entry owns the path name. A blob is content. Renaming a file without changing stored content can result in a different tree but the same blob OID. Git may later detect renames by comparing content; there is no permanent “this blob's filename” field.

3. Failure mode — assuming each commit physically duplicates every file

git rev-parse HEAD~1:stable.txt
git rev-parse HEAD:stable.txt
git rev-parse HEAD~1^{tree}
git rev-parse HEAD^{tree}

If the file is unchanged, the blob OID can be reused even though the commit and often root-tree OIDs differ. Git's pack storage may later compress representations further, so “commit = copied folder” is wrong both logically and physically.

4. Failure mode — treating a branch as an object

git show-ref --heads
git rev-parse --symbolic-full-name HEAD
git rev-parse HEAD
git cat-file -t HEAD

show-ref pairs ref names with OIDs. cat-file -t HEAD reports the type of the resolved target object, normally commit; it does not prove “HEAD is a commit file.” The name is resolved first.

5. Intentionally broken example — an object name that is too short or invalid

Git accepts sufficiently unique hexadecimal prefixes, but not arbitrary strings or ambiguous/nonexistent prefixes. In a disposable repository try:

git rev-parse --verify deadbeef^{object}
git cat-file -t deadbeef

Unless your repository happens to contain an object matching that prefix, Git reports that the revision/object is unknown or invalid. The repair is not to fabricate a longer string. Resolve from a trustworthy name or ask Git for a unique abbreviation:

git rev-parse --verify HEAD
git rev-parse --short=12 HEAD

For untrusted input, also use --end-of-options with rev-parse --verify so a malicious name is not parsed as an option.

6. Failure mode — treating OIDs as signatures

A commit's object identity covers the commit object's bytes, which include tree/parent IDs, author/committer metadata, and message. That does not mean the named author cryptographically signed it. Anyone who can create a commit can place arbitrary author metadata into a new commit object.

Later security lessons distinguish object integrity, cryptographic signatures, trusted signer identity, server authorization, and review/approval policy.

7. Failure mode — editing .git/objects manually

Use supported commands:

git cat-file -e HEAD^{object}
git cat-file -t HEAD
git cat-file -p HEAD
git fsck --full

git fsck checks object connectivity/validity and is appropriate when corruption is genuinely suspected. Interpret dangling/unreachable reports carefully—they are not automatically corruption.

8. Failure mode — confusing “unreachable” with “missing”

An unreachable object may still exist but have no current ref path leading to it. A missing object is absent when another reachable object/reference requires it. These lead to very different recovery strategies.

git fsck --full
git reflog
git show-ref

Preserve the repository before cleanup if recovery matters. Do not immediately prune unreachable objects just because fsck lists them.

9. Red-zone operations that reduce recovery options

10. Security analysis that belongs to the object model

• Integrity: object IDs let Git detect mismatched/corrupt object contents.
• Authenticity: requires signatures or another trusted identity mechanism; an author field alone is not proof.
• Authorization: a server decides who may read/update refs; an OID does not grant permission.
• Confidentiality: content placed in Git history may persist in objects even after a visible ref moves; secret response requires credential rotation plus coordinated history remediation.

11. Performance analysis that belongs here

Do not count loose files and conclude “one file per object forever.” Git can pack objects and use deltas to reduce storage and improve access. Conversely, a huge number of loose objects can be a maintenance signal. Use:

git count-objects -vH

Chapter 22 teaches maintenance tuning. This lesson's key point is that physical storage representation is not the same thing as logical object identity.

12. Symptom → object-model question

13. Knowledge check

14. Summary

Paths live in trees, branches live in refs, logical objects can outlive refs, abbreviations require uniqueness, and physical storage is an implementation layer. Diagnose through Git's object/ref commands and preserve recovery evidence before maintenance or cleanup.

Authoritative references

• git-fsck
• git-rev-parse
• gitrepository-layout
• git-gc