You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[fix] Repair orphaned worktree before removal so clean/remove fully clear it (#407)
* [fix] Repair orphaned worktree before removal so clean/remove fully clear it (#405)
removeWorktreeEntry made a one-shot decision from the list-time prunable
snapshot, so an orphaned worktree (directory present, .git deleted
out-of-band) either died with exit 128 (no fallback) or got pruned while
leaving the directory on disk. Heal via `git worktree repair` before
removal so clean/remove/merge fully clear it instead.
git worktree repair's own exit status is unreliable (it can report failure
while having already rewritten the .git linkfile), so success is judged by
whether the follow-up remove works, not repair's reported status.
* [fix] Drop ticket refs and shorten comments added in this PR
No functional change — trims comments this PR introduced to be
self-explanatory without pointing at issue numbers, per review feedback.
* [fix] Respect --force through the orphan-heal path
healAndRemoveOrphan hardcoded force=true, silently discarding real
uncommitted content in an orphaned worktree regardless of the caller's
--force flag. Thread the real force value through instead, and only
fall back to prune when the .git linkfile is still missing after the
retry — a genuinely dirty (but now-healed) worktree surfaces its real
git error rather than being force-deleted or misreported as pruned.
Also wraps the retried remove's error alongside prune's on total
failure, and renames the operations-layer output fields (RemoveResult/
CleanedItem/MergeResult) from Prunable to LeftOnDisk to decouple them
from the input-classification meaning of Prunable elsewhere. The
public --json field names are unaffected.
0 commit comments