omitting repo headers with 'mr run'

[Adam Spiers]

On Sun, Feb 12, 2012 at 5:16 PM, Joey Hess <joey at kitenet.net> wrote:
> Adam Spiers wrote:
>> 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.
>
> It would be more accurate to say that neither -j nor --quiet can be used
> with interactive actions. mr commit can be an interactive action unless
> -m is provided, so they're certianly supported by mr in general.
>
> One approach could be to add a flag denoting which commands can be
> interactive and refuse to run them with -j or --quiet.

Sounds like a nice idea.  I think this would actually solve both
problems - see below.

> Although mr
> really has no way of knowing if a commit has flags specified that make
> it noninteractive.

Right - not just commit; it's the same problem with any action.  But
you could add support for some kind of test e.g.

    git_wip_is_interactive    = false
    git_commit_is_interactive =
        for arg in "$*"; do
            [[ "$arg" == -m* ]] && exit 0
        done
        exit 1

If this test evaluates to false, then you know it is safe to (a)
parallelise jobs, and (b) capture the output of the action via qx()
rather than execute it (potentially interactively) via system().  In
that case, upon completion of the action you can check whether there
was any output, and then optionally suppress output of the header.  I
actually already have half of a patch for doing this (it adds a new
--empty option), so if this makes sense to you, please let me know and
I'll finish the patch and send it over.

> The other approach is to accept that like all unix
> tools this can be used to shoot yourself in the foot.

Of course everyone has to accept that already.  I don't see how it
translates into a particular course of action though, unless you count
"do nothing" as a course of action ;-)

Going back to my use case above though, I thought of a different
approach: use mr to output a list of which repositories need syncing,
and then write something else which consumes that list and takes
(interactive) action based on it, e.g.

    git_wip = git-wip && echo WIP: $MR_REPO

followed by

    mr wip | awk '/^WIP:/ { print $2 } | while read repo; do
      cd $repo
      git sync-with-upstream
    done

Decoupling the creation of the "TODO" list from its consumption would
mean that the former could be parallelised (output is line-buffered,
right?) without affecting the latter, which is necessarily serial.