remove-tree should warn user if the WorkingTree has uncommitted changes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Fix Released
|
Medium
|
Unassigned |
Bug Description
During one of my reclaim-disk-space frenzies, I went a bit all-out with the remove-tree command on my bzr hive... turned out I have some checkouts that actually had important modifications not committed. However, the behavior of bzr was to leave the unmodified files around (FORTUNATELY) but remove the working tree anyway (unfortunately).
So after I discovered my mistake, I had to go back and do a checkout (which moved my modified files to .MOVE) and do a find+sed+awk job to mass-rename the .MOVED files back, then commit, then remove the working tree again.
I think it'd be very helpful if bzr remove-tree refused to operate on working trees that contain uncommitted changes (i.e. modified, added, removed, unknown files). A --force hammer can be implemented for the extra-sure users, but for general use of remove-tree I'd prefer it if it was a bit more cautious and protective.
Changed in bzr: | |
importance: | Undecided → Medium |
Changed in bzr: | |
status: | Confirmed → Fix Released |