On Thu, Nov 22, 2007 at 01:28:34PM -0800, Junio C Hamano wrote:
> 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.
> (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.
> (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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
