new mr patches on their way (not quite ready yet though)

[Adam Spiers]

On Thu, Dec 1, 2011 at 9:31 PM, Joey Hess <joey at kitenet.net> wrote:
> Adam Spiers wrote:
>> OK.  I'm not entirely sure I understand what you want though.  How
>> would you define self-contained in this context?
>
> Any patch that does not depend on any other patch.

OK, so to summarise, would it be correct to say that you are prepared
to review

  (a) a master branch only containing self-contained commits

and/or

  (b) topic branches which contain a series of non-self-contained
      commits representing a single line of development?

>> IMHO it's an impossible task without color.
>
> Scanning for a new paragraph ("\n\n") is an impossible task?

I have mr acting on ~70 repositories.  Each one results in several
hundred lines of output with -v5 (which is equivalent to your upstream
'-v'), or a minimum of ~15 lines with -v4 (which hides 'lib' code).
So we are talking about either hundreds or thousands of lines of
output.  Therefore to debug certain things (usually issues with one of
my plugins or .mrconfig files) I frequently have to pipe the output to
less(1) and then use a combination of grepping and scrolling up/down
by the page.

Any task becomes impossible if there is no way to work on it
efficiently enough to complete it within the given time constraints.
I'm happy to allocate a certain amount of time per week to contribute
to mr, but I'm not going to work on it in a manner which for me
personally is substantially less efficient than I could achieve with a
small amount of up-front optimization - which in this case is adding a
splash of color.

Any thoughts on the remaining questions?

  1. If I made a debug-levels topic branch or self-contained patch
     in which '-v' (with no numeric argument) behaved how you are used
     to, would you be likely to accept it?

  2. If I made a patch which only enabled color if MR_COLORS was set,
     and where the colors were configurable, would you be likely to
     accept it?