omitting repo headers with 'mr run'

[Michael Henry]

On 02/11/2012 08:27 AM, Adam Spiers wrote:
> However, if I have (say) 70 repositories and only two of them
> have work in progress, `mr wip' outputs about 150 lines, of
> which only 10 lines are useful. [...] Is there any existing
> way I can make it only output the repositories for which the
> git_wip action generates some output?

I've had a similar problem with several of the ``mr`` operations
(``mr up``, ``mr st``, ...).  I've squelched uninteresting input
from long build output (for example) by using the attached
Python script.  I hunted around for something pre-built to do
this job, but I couldn't find anything.  I'd be interested in
pointers to similar tools, if anyone knows of any.

The basic idea is that output from "verbose" tools can be
categorized into interesting lines and mere boilerplate "status"
lines (which are useful only for keeping track of progress or
marking context when an interesting line comes around).

The ``pytee`` utility (attached) works like the standard Unix
``tee`` utility, with the additional ability to detect "status"
lines via user-supplied regular expressions.  For a series of
consecutive status lines that go to the console, each successive
line of status overwrites the previous one "in-place", giving
the impression of a static progress display.  But when a line of
interesting text comes by (that is, a line that doesn't match
the supplied regular expressions), the previous status line is
displayed along with the interesting line.

I alias ``mr`` to the following script, which I call
``mrwrap``::

    #!/bin/bash

    mr "$@" 2>&1 | pytee \
        --regex '^mr (status|update|push): /' \
        --regex '^(Everything|Already) up-to-date' \
        --regex '^\s*$'

That way, interesting output from invocations like ``mr st``
will not be carried away by boilerplate text.

I like that I can wrap existing programs without having to
modify them to make them suitably quiet.  I confess I'd like to
see ``mr`` have some kind of feature like this built-in, but I'm
satisfied enough with my work-around that I haven't mentioned it
until now.

Michael Henry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pytee.py
Type: text/x-python
Size: 4341 bytes
Desc: not available
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20120211/129b2b45/attachment.py>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: README.txt
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20120211/129b2b45/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setup.py
Type: text/x-python
Size: 781 bytes
Desc: not available
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20120211/129b2b45/attachment-0001.py>