Cleanup being unconditional took the decision away from the operator, and the guard that had to compensate was wrong twice — first refusing every unpushed branch, then allowing removal of a tree whose only content was ignored files.
Settled: the guard moves off the worktree and onto the kill. A session whose worktree holds unsaved work is not killed at all, so the session stays as the operator's handle to their own unfinished work instead of the tree becoming an orphan.
DELETE /api/sessions/:id is refused when the worktree has any of:
uncommitted changes to tracked files
untracked files that are not ignored
commits on its branch reachable from no remote-tracking ref
Ignored files never block. Every Rust worktree has a target/; counting those would mean no session is ever killable.
The refusal is a structured error naming what blocked it and how much of it there is, so a client can say "3 uncommitted files, 2 unpushed commits" rather than "failed". The session keeps running and its worktree is untouched.
Note the consequence, accepted deliberately: a feature branch almost always has unpushed commits, so the ordinary way to end a session becomes --force (#E4), which retains rather than destroys.
Depends on: #E1
Cleanup being unconditional took the decision away from the operator, and the guard that had to compensate was wrong twice — first refusing every unpushed branch, then allowing removal of a tree whose only content was ignored files.
Settled: the guard moves off the worktree and onto the kill. A session whose worktree holds unsaved work is not killed at all, so the session stays as the operator's handle to their own unfinished work instead of the tree becoming an orphan.
`DELETE /api/sessions/:id` is refused when the worktree has any of:
- uncommitted changes to tracked files
- untracked files that are not ignored
- commits on its branch reachable from no remote-tracking ref
Ignored files never block. Every Rust worktree has a `target/`; counting those would mean no session is ever killable.
The refusal is a structured error naming what blocked it and how much of it there is, so a client can say "3 uncommitted files, 2 unpushed commits" rather than "failed". The session keeps running and its worktree is untouched.
Note the consequence, accepted deliberately: a feature branch almost always has unpushed commits, so the ordinary way to end a session becomes `--force` (#E4), which retains rather than destroys.
Depends on: #E1
naps62-yolo
added this to the Worktree lifecycle milestone 2026-08-24 09:38:40 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Cleanup being unconditional took the decision away from the operator, and the guard that had to compensate was wrong twice — first refusing every unpushed branch, then allowing removal of a tree whose only content was ignored files.
Settled: the guard moves off the worktree and onto the kill. A session whose worktree holds unsaved work is not killed at all, so the session stays as the operator's handle to their own unfinished work instead of the tree becoming an orphan.
DELETE /api/sessions/:idis refused when the worktree has any of:Ignored files never block. Every Rust worktree has a
target/; counting those would mean no session is ever killable.The refusal is a structured error naming what blocked it and how much of it there is, so a client can say "3 uncommitted files, 2 unpushed commits" rather than "failed". The session keeps running and its worktree is untouched.
Note the consequence, accepted deliberately: a feature branch almost always has unpushed commits, so the ordinary way to end a session becomes
--force(#E4), which retains rather than destroys.Depends on: #E1