muse pull does not prune stale remote tracking refs after hub-side branch deletion
Summary
When a merge proposal is merged on the hub with 'Source branch deleted', the tracking ref under .muse/remotes/<remote>/<branch> is not removed by the subsequent muse pull. The user must run muse fetch <remote> --prune as a separate explicit step.
Steps to reproduce
- Push a branch and create an MP
- Merge the MP on the hub (source branch auto-deleted)
muse switch dev && muse pull local devtree .muse/remotes— stale tracking ref still present
Expected behavior
muse pull local dev should behave as muse fetch local --prune && muse merge local/dev — pruning any tracking refs for branches the remote no longer reports. At minimum, the MP merge response (which confirms source branch deletion) should trigger a prune of that specific ref.
Actual behavior
Stale tracking refs accumulate silently. The only way to clear them is an explicit muse fetch <remote> --prune.
Context
This surfaced during a remote branch cleanup session. After merging MP #8 into local dev, .muse/remotes/local/fix/proposal-closed-state-badge persisted until manually pruned.
Proposed solution:
fetch.pruneconfig optionMirror git's
fetch.prunebehavior exactly.Config (set once, applies to all fetches in that repo):
Behavior when set:
muse fetch <remote>— prunes stale tracking refs automaticallymuse pull <remote> <branch>— prunes as part of the fetch stepBehavior when unset (default): current behavior — no pruning, explicit
muse fetch <remote> --prunerequired.Global variant (applies across all repos on the machine):
This is the exact pattern git uses (
git config --global fetch.prune true). Agents and humans who set it once never have to think about stale tracking refs again. The--pruneflag onmuse fetchstays as an explicit one-shot override regardless of config.