Conflict while using "bzr pull"

[Jamie Wilkinson]

This one time, at band camp, James Blackwell wrote:
>On Wed, Dec 14, 2005 at 12:28:23PM +1100, Jamie Wilkinson wrote:
>> This one time, at band camp, James Blackwell wrote:
>> >On Mon, Dec 12, 2005 at 09:53:28AM -0500, Aaron Bentley wrote:
>> >> Actually, I just do "rm * -R; bzr revert".  Because .bzr doesn't match
>> >> the * glob, but almost everything revert cares about does.
>> >
>> >Grin. When I read his post, I read it as "rm -rf branch/*""
>> >
>> >> > What do people think, should we have a "bzr revert --force", or maybe a
>> >> > "bzr revert --everything". I think it would be nice to have a single
>> >> > command which says, "I know things are messed up right now, get me back
>> >> > to exactly FOO, so I can continue with my life".
>> >> 
>> >> Perhaps "bzr revert --pristine" would delete all unversioned files as
>> >> well as restoring source files to the correct names and contents.
>> >
>> >-1 to pristine. Though archers know it, it not in the common venacular.
>> 
>> -1 to both, because I think it'd be uncommon enough situation that bzr
>> doesn't need to go to the trouble (and thus maintenance and testing load) to
>> support it; "rm -R *; bzr revert" is good enough.
>
>Hm. I think that having "rm -R *" as part of the normal work vocabulary
>is someting that should be avoided unless necessary. I probably won't
>cause much damage if I run "bzr revert --full" when in my home directory.
>A "rm -R *" on the other hand....

My point is that it's not *normal* work vocabulary.  Of everyone on the
list, only John and I reported experiencing this problem.  It sounds like
it's a bug in pull, if anything.  If that's the case, then it needs fixing,
not a new command to act as workaround for when it happens.