Problem
When a file is added to .gitignore (or otherwise untracked from git), its drawers remain in the palace indefinitely. There is no way to detect and remove these orphaned drawers without manually running mempalace purge --wing <x> --room <y> or writing a custom ChromaDB script.
Concrete example: A project folder with ~10k files was mined into a room. The folder was later added to .gitignore. The room still holds 10,547 drawers with no supported way to bulk-remove them short of a custom Python script querying ChromaDB directly.
Proposed solution
Add a --sync flag to mempalace mine (or a standalone mempalace sync command) that:
- Reads
source_path metadata from all drawers in the target wing/room
- Checks each path against the current git-tracked file list (
git ls-files) and the .gitignore rules
- Deletes drawers whose source file is no longer tracked (gitignored, deleted, or moved)
mempalace mine --sync # prune orphans in current repo's wing
mempalace mine --sync --wing iis # scope to one wing
mempalace sync --wing iis --room old-dir # explicit sync command
Why this should be default (or at least easy)
The mine workflow already tracks filed_away state per file to avoid re-mining. The inverse — removing stale entries — is the natural complement. Without it, palaces grow unboundedly and searches return results for files that no longer exist in the project.
A reasonable default would be: when mempalace mine is run in a git repo, automatically prune drawers whose source_path is now gitignored. This mirrors how tools like ripgrep and git ls-files naturally respect .gitignore.
Related
Neither addresses retrospective cleanup of gitignored files.
Problem
When a file is added to
.gitignore(or otherwise untracked from git), its drawers remain in the palace indefinitely. There is no way to detect and remove these orphaned drawers without manually runningmempalace purge --wing <x> --room <y>or writing a custom ChromaDB script.Concrete example: A project folder with ~10k files was mined into a room. The folder was later added to
.gitignore. The room still holds 10,547 drawers with no supported way to bulk-remove them short of a custom Python script querying ChromaDB directly.Proposed solution
Add a
--syncflag tomempalace mine(or a standalonemempalace synccommand) that:source_pathmetadata from all drawers in the target wing/roomgit ls-files) and the.gitignorerulesWhy this should be default (or at least easy)
The mine workflow already tracks
filed_awaystate per file to avoid re-mining. The inverse — removing stale entries — is the natural complement. Without it, palaces grow unboundedly and searches return results for files that no longer exist in the project.A reasonable default would be: when
mempalace mineis run in a git repo, automatically prune drawers whosesource_pathis now gitignored. This mirrors how tools like ripgrep andgit ls-filesnaturally respect.gitignore.Related
mempalace purge— delete drawers by wing/room #1087 adds manualmempalace purge --wing/--room(workaround, but manual)--excludeflag for mine (prevents future mining, doesn't clean existing)Neither addresses retrospective cleanup of gitignored files.