On Sun, 10 Feb 2008, Linus Torvalds wrote:
>
> Yes, the 10% that actually *cares* will look exactly the same (the
> difference being comparing against NULL or config_true), but all the stuff
> that compares against a special string can just ignore the fact that the
> special truth value will never ever match that string.
And here's an example of this kind of effect. I'm not actually suggesting
you apply this patch, but tell me it isn't simpler done this way?
So this is where it *does* make a difference whether we use NULL or
config_bool, and where config_bool is simply better: it allows a config
routine to simply never care..
Linus
---
color.c | 15 ++++++---------
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/color.c b/color.c
index cb70340..e5fbf01 100644
--- a/color.c
+++ b/color.c
@@ -118,15 +118,12 @@ bad:
int git_config_colorbool(const char *var, const char *value, int stdout_is_tty)
{
- if (value) {
- if (!strcasecmp(value, "never"))
- return 0;
- if (!strcasecmp(value, "always"))
- return 1;
- if (!strcasecmp(value, "auto"))
- goto auto_color;
- }
-
+ if (!strcasecmp(value, "never"))
+ return 0;
+ if (!strcasecmp(value, "always"))
+ return 1;
+ if (!strcasecmp(value, "auto"))
+ goto auto_color;
/* Missing or explicit false to turn off colorization */
if (!git_config_bool(var, value))
return 0;
-
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
