bzr with bzr+ssh noisy and output muddled.

Maritza Mendez martitzam at
Thu Jun 18 01:47:16 BST 2009

As a user I agree both with your prioritization and that strict
enforcement of --quiet (which is not yet) is a worthy goal for bzr.


On 6/17/09, Martin Pool <mbp at> wrote:
> 2009/6/18 Maritza Mendez <martitzam at>:
>> Martin,
>> Thank you for your collaborative leadership.
>> When I started using Unix 20 years ago (Hey!  I'm still younger than
>> *some*
>> of you!)  the first thing I remember learning is "simple tools that do
>> one
>> thing well."  The second thing I learned was "succeed silently."  I don't
>> know if Unix community can claim these as original, but they're good
>> principles.  And like all the best principles, there are exceptions.
>> So I would like to see an option to tell bzr to essentially "keep quiet
>> unless there is a problem" which would be accessible by (and hopefully
>> honored by) all bzr commands.  Quiet does not have to be the default.
>> Being
>> available (and documented) is enough.  This will make bzr script
>> friendly.
>> Finally, I would vote to keep the progres bar available even after
>> transports are prefected.  There will be bugs, maybe not even caused by
>> bzr.  Knowing right away what stage the failure occurred in could really
>> speed up debugging.
> There is a --quiet option, and there is
> <> asking that it
> should also turn off the progress bar, as well as other messages.  (It
> probably does not suppress every message that it should at present.)
> I think at the moment getting the other aspects of progress display
> right is more important.
> --
> Martin <>

Sent from my mobile device

More information about the bazaar mailing list