prune is still inconsistent and broken #449
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#449
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?
prune is still broken:
The 500-error half is fixed and merged (PR #462): a delete of an already-gone remote ref (500 "object does not exist [id: refs/heads/...]") is now classified as already-gone, not an error, so the six spurious "API error 500" lines are gone. That was the actual breakage.
Two things stay open for a decision.
1. Display of defect 1. A squash-merged branch whose live remote twin is also deleted (e.g. fix-mcp-conformance-mark-expected-error) still appears under BOTH "Deleted remote branch(es)" and "Deleted squash-merged branch(es)". This is truthful, not a double-delete: its local ref goes to the squash-merged list and its remote twin is folded into the remote list (the #301 fold), and each ref is deleted exactly once. But it reads as a repeat. Options:
I lean to the separate line: it keeps every deletion named (the "nothing deleted that is not reported" invariant) while removing the read-as-double-delete. It reverses the documented 2026-07-10 fold, so the call is yours.
2. A defensive guard I added, disclosed. The merged fix also carries a skipRemotes guard so a branch reached by both the ancestry and the squash-merged pass deletes its remote twin at most once. The two candidate sets are disjoint by construction today (findSquashMerged excludes ancestry-merged branches), so the guard never fires in practice - it is defensive, not a live path. I kept it self-documented, but it is removable if you prefer it lean, and the display change in (1) touches this same area, so both can be reconciled together.
Marking needs-decision on (1).
Decided: give squash-merged remote twins their own line.
Add a "Deleted squash-merged remote branch(es)" heading (a new result field plus the format-layer change) so each branch appears under exactly one heading. This keeps the "nothing deleted that is not reported" invariant while removing the read-as-double-delete. It reverses the documented 2026-07-10 #301 fold, which is the intended change here.
The 500-error breakage was the real bug and is already fixed (PR #462).
Companion, reconciled in the same change: remove the never-firing
skipRemotesguard.findSquashMergedexcludes ancestry-merged branches, so the two candidate sets are disjoint by construction and the guard cannot fire. With each branch now shown under exactly one heading, the dead guard adds nothing. If you would rather keep it as defensive scaffolding, say so and I will leave it self-documented.Clearing needs-decision.