remove-tree should warn user if the WorkingTree has uncommitted changes

Bug #74101 reported by John Dong
2
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.

Revision history for this message
Jelmer Vernooij (jelmer) wrote :
Changed in bzr:
status: Unconfirmed → Confirmed
Martin Pool (mbp)
Changed in bzr:
importance: Undecided → Medium
Jelmer Vernooij (jelmer)
Changed in bzr:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.