A functional subset of Git built from scratch — same object model, same content addressing, same DAG structure. Blobs, trees, and commits are stored as zlib-compressed SHA-1-addressed objects, just like real Git.
| Command | Description |
|---|---|
pygit init |
Initialize .pygit/ repository |
pygit hash-object <file> |
Store file as blob, print SHA-1 |
pygit cat-file <sha> |
Read and decode a stored object |
pygit add <file> |
Stage file (update index) |
pygit write-tree |
Write index snapshot as tree object |
pygit commit-tree <tree> -m <msg> |
Create commit object |
pygit commit -m <msg> |
Stage all + commit (porcelain) |
pygit log |
Walk commit DAG, print history |
pygit checkout <sha> |
Restore working tree from commit |
pygit status |
Compare index vs working tree |
pygit diff |
Show unstaged changes |
python3 pygit.py init
echo "hello" > hello.txt
python3 pygit.py add hello.txt
python3 pygit.py commit -m "Initial commit"
python3 pygit.py logcommit a3f1c8...
Author: pygit
Date: 2024-01-01
Initial commit
Blob — raw file content (zlib-compressed, SHA-1 addressed)
Tree — directory snapshot: list of (mode, name, sha) entries
Commit — tree SHA + parent SHA + author + message
↓
.pygit/objects/ab/cdef123... (2-char dir / 38-char file)
- How Git's content-addressable storage works: SHA-1 hash of
"type len\0content"determines the file path - Why commits form a DAG (directed acyclic graph): each commit stores its parent's SHA, enabling history traversal
- How
git addworks: the index is a snapshot of staged file paths → blob SHAs, not file contents - The difference between plumbing (
hash-object,write-tree) and porcelain (commit,log) commands
Built as part of the Build Your Own X curriculum.