Re: [PATCH 3/4] push: make non-fast-forward help message configurable

[Jeff King <peff@peff.net>]

On Mon, Sep 07, 2009 at 10:34:25AM +0200, Matthieu Moy wrote:

> > So really they are two different conceptual types of message. And while
> > I have no problem with an argument of "I _personally_ find this clutter
> > and would like to configure it off", I don't think such an option should
> > go under "advice.*". My patch had "message.all" (which will become
> > "advice.all")
> 
> To me, this is an argument in favor of keeping "message", to allow the
> same mechanism for these different types of messages.
> 
> But I think the individual message.* should not be just true/false
> switch, but could be always/auto/never :
> 
> - always: show the message, regardless of message.all
> - auto (the default): rely on message.all to decide whether to show
>   the message
> - never: never show it.
> 
> So you could say "message.all = false" and "message.resetShowsNewHead
> = always".
> 
> But maybe that's just overkill, dunno...

I'm not sure it solves the problem. The point of "message.all" was to
easily say "I'm an expert, so turn off useless advice". But now I would
have to manually re-enable any messages that I _do_ want to see. And of
course I don't see them to know that I want them, so I have to read
through the config documentation and decide on each one.

At that point, why not just get rid of "message.all" and simply say
"manually turn off the messages you don't like". Then the user can
either go through the config manually as above, or they can wait until
they become annoyed with a particular message and turn it off (and
hopefully our naming is good enough that they can easily figure out
which one it was :) ).

So I think "be verbose, but let the user quiet us" is probably
better than "be quiet, but let the user make us louder", because it is
easier to discover verbose things. Which implies to me that
"message.all", if it exists at all, should be limited in scope to just
advice.

In fact, you could mix many types in the message.* hierarchy and simply
call the umbrella variable message.advice. But that is semantically
equivalent to having advice.{all,*} and other_type_of_message.{all,*}.

-Peff