A .gitignore line silently hid my dataset

I moved my dissertation project to a new machine and discovered it could no longer rebuild its own dataset. The folder describing exactly which documents went into the system's knowledge base (ten manifest files) was simply gone. It had never been committed. Not once.

The culprit

My .gitignore contained a line many Python projects carry without thinking: MANIFEST. It's meant for a single packaging file at the root of a repository. But a gitignore pattern with no slash in it matches at any depth, and the folder was called ingest/manifest/. On Windows, git runs with core.ignorecase = true, so MANIFEST matched manifest too.

No warning. No error. git status just never mentioned the files, so I never noticed.

The fix

• Anchor the pattern to the root: /MANIFEST matches only the packaging file it was meant for.
• Add an explicit re-include for the folder that matters: !ingest/manifest/.
• Verify: git add --dry-run ingest/manifest/ should now list all ten files.

Check your own repository

Run git status --ignored and read the list. For anything surprising, git check-ignore -v <path> tells you exactly which line of which ignore file is responsible. It takes two minutes, and it's the kind of check that belongs on every release checklist.

Why it matters beyond my project

Nothing failed loudly. The project quietly lost the ability to reproduce itself, and nobody would have known until someone changed machines. That's the kind of failure worth designing against in any system that keeps records: not a crash, but a silent gap between what we think is recorded and what actually is.