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

[Adam Spiers]

On Thu, Dec 1, 2011 at 7:57 PM, Joey Hess <joey at kitenet.net> wrote:
> Adam Spiers wrote:
>> Thanks for the reply.  Sure - I can syphon those commits off into a
>> stow branch.  It bothered me too that they were non-contiguous.  In
>> fact, I appreciate that just dumping a whole load of uncategorised
>> commits on your doorstep isn't particularly helpful, so maybe it's
>> better if I create a branch for each change, and then point you at
>> each branch.  Would that work for you?
>
> There's no need for a separate branch for self-contained changes.

OK.  I'm not entirely sure I understand what you want though.  How
would you define self-contained in this context?

> I have not looked at the colors in use here, but IME adding color to
> terminal programs is often badly done, resulting in an angry fruit salad
> effect, and often needing additional configuration to disable it, or
> to tweak the colors to ones visible for colorblind users or users who
> cannot read yellow text on a white background.

Very valid points.  Pretty much all I've done is use red for errors,
yellow for skips, green for success, and bold white for the initiation
of each action, but I can see how this could cause problems.  Would it
make you happier if it was disabled by default and/or theme-able?

> Which I can put up with in a mail reader, git diff, or a text
> editor, but given the very small amount of output done by mr, seems
> likely excessive. I suppose the idea is to pick out errors from
> amoung the rather larger amount of output displayed by the version
> control system,

That's certainly part of the idea, but it's also very useful for
things like 'mr status'.

> but mr already tries to
> structure its output to make it easy to do that.

IMHO it's an impossible task without color.  I'm an mr newbie and I
already have about 70 repositories, so for me there's just way too
much output.  When I first switched to mr, I found virtually
everything else about it extremely nice, but despite trying hard, my
eyes just couldn't deal with that vast expanse of white text.  Even
the single use of bold white for each action "header" instantly made
life a lot easier.

>> Regarding debug levels: without a more fine-grained approach to
>> logging, it would have been too hard for me to understand mr's
>> internals and achieve all the development I was able to.  A large part
>> of the challenge for me was understanding the order in which mr parsed
>> / executed things etc. and the original -v was way too verbose to be
>> able to trace this - it would have required me to keep too much stuff
>> in my head at once.  In fact, there were a few minor bugs which I
>> spotted precisely because I entered this debugging exercise.
>>
>> Having said that, I freely admit that a debugging system based on
>> numeric levels isn't particularly elegant or sophisticated, and I'd be
>> happy to see something better.  But it's a very standard technique
>> industry-wide (c.f. syslog and hundreds of other logging software
>> projects which use the concept of "priorities" or "severities"), and
>> it was also The Simplest Thing That Could Possibly Work.
>
> I have never seen such a debugging system in which I did not use exactly
> two modes: none, or "turn the dial to 11 and grep for the thing I
> actually wanted".

Sure, each to their own, but I think it's far to say that a *lot* of
developers, myself included, struggle to work like that.  In
particular, grepping is no use when you are trying to learn the
high-level flow of a program you didn't write yourself.

There's an easy technical solution which would keep us all happy
though - provide the more fine-grained control, make a default
verbosity of 1 or 2, and then make -v with no argument bump it up to
the maximum value (currently 5 I think).  So from your point of view,
there's no noticeable change in behaviour.  In fact this is how I
originally coded it, but at some point I seem to have dropped that
behaviour.

>> Because it's up to the end user whether he wants to stow the
>> repository or not, and that decision is entirely dependent on the
>> context in which the repository is being used.
>
> But is there no way to tell if a repository is stowed? Why couldn't the
> checkout just handle registering it with stow (or whatever), and then
> the other actions could check to see if it was so registered.
>
>> Wanting to use mr to manage the download and installation of a piece
>> of software is weird?  Or the implementation is weird?
>
> Wanting to use mr to manage software not in version control is weird. :)

Why?  Maybe it's not what the tool was originally envisioned for, but
that doesn't necessarily mean it's a bad idea.  Automating and
tracking non-root installation procedures for software makes the
process explicit, reliable, reproducible, and scalable.  It's a bit
like puppet or cfengine but operating at the user- rather than
system-level.