fastimport silently trashes .bzr directory in parent directory
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar Fast Import |
New
|
Undecided
|
Unassigned |
Bug Description
I was experimenting with fastimport and typed:
mkdir ~/test
cd ~/my-bzr-repo
bzr fast-export . ../test/test.fi
cd ../test
bzr fast-import test.fi project.bzr
Note that the directory ~/test/project.bzr doesn't exist. The documentation says that in this case, project.bzr will be created.
I expected that project.bzr would be created, but instead the fast-export command clobbered ~/.bzr and replaced it with the newly imported repository. Before that, the ~/.bzr directory contained the repository for the dot files in my home directory. (I recovered the .bzr directory from a backup, so no harm was done.) The directory project.bzr was _not_ created. Once I realized that this had happened, I expected to just have to do 'bzr uncommit' a few times to get rid of the unintended commits. However, it seems that fast-import completely clobbered the .bzr directory: bzr claimed to have only the commits from the fast-import command, and claimed that my dot files were not being tracked.
I am using Python 2.7.3, bzr version 2.5.1, fast-import version 0.13.0, on OS X 10.7.5
I would consider some or all of the following to be improvements over the present behavior
1) Warn before clobbering an existing, non-empty bzr repo
2) If the user specifies a destination, use that destination. Don't clobber a .bzr directory somewhere else in the filesystem
3) Print a message "I am about to do XYZ to the bzr repository in ABC, proceed (y/n)?"
4) Require fast-import to create/modify bzr repos in directories _below_ the present directory, not _above_. The present behavior allows potentially dramatic changes to bzr repos in unexpected places. (I realize that keeping my dot files in bzr, so that no matter where I am in my home directory, bzr is able to run up through parent directories until it finds ~/.bzr and therefore think that it's in a bzr repo is, perhaps, a hare-brained thing to do, and therefore I take some of the blame for this)