fix: muse code add unconditionally wrote EMPTY_DIR_OID to the object store, polluting it on every single invocation
Reported live: staging one plain file (e.g. .museattributes) produced two objects in the store instead of one -- the real content blob plus a suspicious second blob of zero bytes, hashing to blob_id(b'') (EMPTY_DIR_OID, the shared sentinel for empty-directory entries).
Root cause: run_add() called write_object(root, EMPTY_DIR_OID, b'') unconditionally, right before the loop that stages newly-added empty directories -- regardless of whether that loop (or the deleted-committed-dirs loop right after it) actually had anything to do. Staging a single root-level file with zero directories involved at all still triggered this write on every invocation.
Fixed by gating the write on empty_dirs_to_stage or deleted_committed_dirs actually being non-empty -- the sentinel is only written when this invocation genuinely references it.
Audited the sibling call site in mv.py (muse mv's directory-rename path) with the identical comment/pattern -- confirmed it's already correctly scoped inside the directory-move branch, not unconditional at module scope, so it doesn't share this bug.
Semantic Changes
4 symbols
Files Changed
~2
1261 in snapshot
0 comments
muse hub commit comment sha256:5cecc36811c041829d68ecd34bb2d05d9ca81b39d59b14cd47f604f90110cd49 --body "your comment"
No comments yet. Be the first to start the discussion.