Jeff King wrote:
(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).
As you said, config_* converts git values to perl values. However, that conversion needs only be done for strings in .gitconfig. Is there any reason why the caller of the function would need to pass a string "false"? I just don't see the need for conversion of any kind.
Further, I think that we could return the default variable directly, without parsing it at all. It would be much simpler, and there would need to be no special cases for dealing with undef or 'false'. It's a perl function, being called with perl arguments, so a user should not be that surprised when 'false' does what perl says it should do.
Dan - 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
