bug(prune): bare madtea prune deleted remote refs - bare run MUST be a pure dry run, guaranteed by test #133
Labels
No labels
breaking
bug
documentation
enhancement
epic
good first issue
help wanted
refactoring
resolution/duplicate
resolution/invalid
resolution/wontfix
security
severity/critical
severity/high
severity/low
severity/medium
status/abandoned
status/blocked
status/needs-decision
status/needs-info
status/needs-verification
testing
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sixfold-space/madtea#133
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A bare
madtea prune(no flags) deleted remote refs without any confirmation (observed live, 2026-07-15). The declared contract says the opposite: internal/cmd/prune/prune.go:29 "By default, shows what would be deleted (dry run). Use --yes to actually delete", with--yesdefaulting false (prune.go:42) and--dry-runaccepted only for ergonomics because dry run is supposedly the default (prune.go:20).So some code path mutates ref state during what is documented as a pure preview. Candidates to investigate:
git push --delete) on a path not gated by the confirm/yes flag;git fetch --prune(or equivalent) run during enumeration - that deletes local remote-TRACKING refs (origin/*) as a side effect, which still violates a pure dry run even though it does not touch the server;Hard requirement
A bare
madtea prune(and madt_prune without confirm=true) performs ZERO mutations: nothing deleted on the remote, no local branches deleted, no remote-tracking refs pruned, no ref state changed at all. Preview output only.Asks
Acceptance