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

[Adam Spiers]

Hi Joey,

On Thu, Dec 1, 2011 at 6:56 PM, Joey Hess <joey at kitenet.net> wrote:
> Adam Spiers wrote:
>> I've made a lot of progress since this last mail, and I'm conscious
>> that my branch is now approximately 50 commits ahead of the official
>> master branch, so I think it's time to work on convergence if
>> possible.
>
> It would be helpful if you:
>
> * separated the stow stuff into its own branch
>
>  When adding a feature, I need something I can diff against;
>  a chain of commits is ok, or a squashed commit is ok;
>  a chain of commits mixed in with other unrelated changes is not

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?

> * wrote commit messages that were longer than one line
>  I need to understand a commit before I can apply it, and the choice is
>  either that you type a little but more, or that I spend significant
>  time guessing and likely miss something.
>
>  A commit such as a2515e7e89f35c8d3291da9a5908b42a8d0bb277
>  is simple on its face, but is entirely lacking in an explanation
>  of why the change was necessary; in what situation is there a dangling
>  symlink and how did mr fail? Why is adding an error message
>  of "BUG: this shouldn't happen" justified?
>
>  Similarly, commit 655f0002ae80e21329ace97447a3a16c577949ec
>  says it fixes "a small bug", but neglects to say what the bug is.

Sure, I can beef up commit messages too.

>  A commit such as 49163f09b8ff2c70c64076040be772b8d37c84aa or
>  1dd662640b946d681683c260f1b693cd0522b09f needs significant
>  justification -- how does hardcoded VT100 color codes or a lot of
>  different debug levels make mr better?

Regarding color: well, I'm not sure on what level the question is
asked, so forgive me if I'm treating a more technical question as a
philosophical one ;-) If it's whether the use of color makes the
program any more useful, then I guess it's a matter of individual
taste, and I'm aware that some people don't like it.  Each to their
own, but personally I find that rather mystifying - after all, how
many people do you know who use a web browser which renders everything
in black and white?  Or even within the terminal / CLI environment,
how many people dislike the colors generated by ls(1) or git enough to
go to the trouble of disabling them?

It's well known that when used correctly, color can hugely aid the
brain's visual processing process.  Of course, the coloring feature
can be made optional, and as you may have noticed, my patch already
automatically disables color if STDOUT is not connected to a tty (so
that mr | grep etc. work as expected).  I would be happy to add
support for an MR_COLORS environment variable if that made the patch
more agreeable.

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.

> * avoid entangling different lines of development
>
>  I was about to cherry-pick c4a8af985f525c2a1061576e72d526aa515151be
>  until I noticed the last line ties it into the logging level stuff.

I absolutely agree in principle - the problem is that the further my
branch diverges, the less possible this becomes, because unfortunately
the various lines of development are not 100% orthogonal.  That
particular commit you reference is a good example, because there's not
much point having a more fine-grained logging system unless you
actually use it.

> Is there really no way to detect that a given repository is "stowable"
> by looking at the content of the repository or some other thing?

No.

> Why not?

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.

>>   - A plug-in module which allows tar balls / zip files etc. to be
>>     downloaded, unpacked, and used as repositories with minimal
>>     effort, e.g.
>>
>>       [foo]
>>       checkout = mr_download_checkout http://example.com/foo.tar.bz2
>
> A weird feature IMHO,

Wanting to use mr to manage the download and installation of a piece
of software is weird?  Or the implementation is weird?

> but I use lib/* is sort of a contrib area and I'm
> willing to accept most any type of module into it.

OK, great ;-)