clean-tree in bzr core?

John Arbash Meinel john at
Sat Aug 2 16:25:19 BST 2008

Hash: SHA1

Daniel Watkins wrote:
> On Sat, 02 Aug 2008 16:00:05 +0200
> Jelmer Vernooij <jelmer at> wrote:
>> Are there any objections to moving clean-tree into the core, thoughts?
> +1 for moving the functionality in.  I didn't even realise that it was
> part of bzrtools.  However, it might make sense for it to be part of
> reconfigure, rather than a separate command...

I don't think you would do "bzr reconfigure --clean".

It was proposed a while ago, and the main problem is that the defaults for a
bzr tree isn't really appropriate for all other trees. (It used to clean out
the testbzr000X.tmp directories, etc.)

At least I primarily use 'bzr clean-tree --detritus'. I know some people like
unknowns, but I always commit with --strict, because I don't want to forget to
add something. And 'bzr clean-tree' would delete those precious files. So I
make sure to name my temp files something that is ignored.

I suppose I also have "nuke = clean-tree --detritus --unknown --ignored" to
just restore it to pristine. But I don't often want that, because it gets rid
of the compiled code.

Anyway, now that bzr doesn't leave as many temp files in the working tree, the
default list for '--detritus' would be smaller, and it would be more applicable.

I think Aaron's feeling was that if it didn't prune everything out of bzr
tree's, it wasn't useful enough for him. So he wasn't going to do the work to
get it merged.

It also is a good case for the "ignored/precious/garbage" discussion. As 'bzr
clean-tree --garbage' would be a nice thing to have.


I think it would be fine to bring in. I'm curious how other people would use
it, and how you feel it would be appropriate for a generic project, rather
than its current fairly bzr-specific implementation.

Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the bazaar mailing list