omitting repo headers with 'mr run'

[Adam Spiers]

On Sat, Feb 11, 2012 at 9:02 PM, Michael Henry <vcs-home at drmikehenry.com> wrote:
> 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.

Thanks for sharing, Michael.  It's just occurred to me that there's
another related challenge - supporting interactive actions.  Now that
I have the above-mentioned 'wip' test to see whether a repository has
work in progress, the next step is to take some manual action when the
test succeeds.  For example, if there are untracked changes or files,
the action required is to commit them.  If there are some changes
upstream not yet in the local repo, I want to do a pull, and a push if
vice-versa.

I've automated this workflow into another script called 'git-dwim'
(i.e. "Do What I Mean"), although it could equally be called
'git-sync-with-upstream'.  Of course now I want to run this across all
my repositories via mr, but mr currently assumes that actions are
non-interactive (until they fail and the --interactive switch is
given).  For example, if --quiet is provided, all output from the
action is captured, and then only output if the action returns a
non-zero exit code.  Clearly this is not compatible with interactive
actions.

So a further question for Joey is: how could we support interactive
actions? (i.e. where STDIN/STDOUT/STDERR are connected to a tty)