feat: reflog entries for worktree add/remove (muse#54 item 9)
Creating a worktree with -b (a new branch) wrote the branch ref directly via write_branch_ref() with no reflog trace -- a genuine untracked ref move, unlike every other branch-creation path in this codebase. Fixed by appending a "branch: created from <base> via worktree add" entry immediately after.
Plain `worktree add` (reusing an existing branch) and `worktree remove` don't move any ref at all -- the branch itself is untouched either way -- so there's no ref transition to log in the strict sense. Logged same-value audit entries (old_id == new_id) on the worktree's branch instead, noting the worktree lifecycle event, matching this codebase's existing convention of logging non-moving events too (e.g. checkout's "already_on" case).
`worktree remove` captures the worktree's branch via list_worktrees() before remove_worktree() deletes its metadata, since there'd be nothing left to look up afterward.
New tests/test_worktree_reflog.py (4): add on an existing branch logs the worktree-created entry, add with -b logs both the branch-creation entry and the worktree-created entry (correctly ordered oldest-to-newest since both land on the same new branch's log), remove logs the removed entry, and removing a nonexistent worktree still fails cleanly (unaffected). Confirmed genuine RED (3/4 failed) before GREEN with the fix restored.
Targeted regression suite -- the new file plus test_cmd_worktree.py, test_cmd_worktree_hardening.py, test_worktree_supercharge.py, test_core_worktree.py -- all pass (306 passed), zero regressions.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Semantic Changes
23 symbols
Files Changed
+1
~1
1222 in snapshot
0 comments
muse hub commit comment sha256:2b0e51e0e3e2002ffcf41dc5a1349af31d3eee4751d379cc6a8f100a20f9bd9c --body "your comment"
No comments yet. Be the first to start the discussion.