Comment 6 for bug 287880

I would like to see this bumped in priority. The request was posted in '08 and it is now '12. There are use-cases where non-recursive status is important. This is also perhaps more important to people coming to bzr from other VCS where it is available. Bzr seems to place a higher priority on supporting a variety of use cases and work flows. In my case, I use the limit recursion option a lot in the VCS I am trying to move away from. This is one of those things that is reasonable, even from the point that other commands have a --no-recurse option. It seems silly to have to get status on much more than what one is working on at the moment, even if it is "efficient" from a software point of view. It is inefficient for a user to have to sort through more information coming out of status than what is wanted.

Part of the reason I think it is important is that I have a use case where there are unreadable files in the lower trees. bzr status aborts when it sees those unreadable files. Unless I can limit recursion, it is going to be hard to use bzr the way I use my other VCS in this use case. While it is acknowledged that there are alternative ways to approach this problem - and that my particular use case may not be particularly common, it seems reasonable to have bzr to act like other VCS by offering no recurse when getting status.