On Thu, Nov 22, 2007 at 01:28:34PM -0800, Junio C Hamano wrote:

quoted text
> I think the "config_bool with default" also makes sense but it
> needs to be coded a bit carefully.  Issues to consider:

Yes. It is not strictly necessary for this patch series, but I think it
is nice to stake out a claim on the third argument of config_* functions
for consistency sake. But perhaps in the name of avoiding regression, it
should come later, when somebody actually wants to use it.

quoted text
>  (1) Non default form "$r->config_bool('key')" should keep the
>      original semantics; missing key in the configuration is the
>      same as false (i.e. "undef" in scalar, () in list context).

Yes, this is obviously the most important thing.

quoted text
>  (2) What should be the second parameter in the form to default
>      to true?  '1'?  'true'?  Any kind of "true" value in Perl
>      should be accepted?
> 
>  (3) Same question as (2) but for defaulting to false.  Any kind
>      of "false"?

Hmm. I am tempted to say "yes, any true or any false value" in that the
point of config_* is to convert git config values to native perl
representations. OTOH, the moral equivalent of

  config_color('my.key', 'bold red');

is probably more appropriately

  config_bool('my.key', 'true');

so I am fine doing it that way, as well (though I think it makes us
duplicate the "translate these strings into bools" code into perl).

-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html