Pirate Ship Pyc In Git
What Happened

The pirate_ship initial commit (8cffdb2, Jul 6) included an entire Python venv (claude-env/) : 1,469 files, 270K lines. When the project was rebuilt on Aug 24, a .gitignore was added, but .pyc files that were already tracked kept appearing in subsequent commits. By the time we noticed, __init__.cpython-311.pyc alone had 46 recorded changes : more churn than any actual source file. An 8.5MB SQLite database file had also been committed.
Root Cause
Git tracks what it knows. Adding .gitignore tells git to stop tracking new files matching the pattern, but it does nothing about files already in the index. The .pyc files were committed before the .gitignore existed, so git continued tracking them through every Python rebuild. The claude-env/ venv was committed in the first place because there was no .gitignore at all for the initial commit.
How to Avoid
- Create
.gitignorewith__pycache__/,*.pyc,*.pyo, andvenv/before the firstgit add - If binary files are already tracked:
git rm -r --cached __pycache__/then commit the removal - Merge conflicts on binary files during parallel PRs (like a Codex agent blitz) are a symptom : the root is tracked binaries, not the PR workflow
Related
- projects/pirate-ship/_index : parent project
- pirate-ship : project context
- dependency-locking-for-cloud-builds : related build hygiene pattern