Jeff King <peff@xxxxxxxx> writes: > It seems like it would be more convenient if you could pass it a bool > value to turn the "auto" into. E.g., if you could do: > > b = git_parse_maybe_tristate(value, 1); /* default to "1" */ > if (b < 0) > do_error(); > if (b) > do_true(); /* true, or maybe "auto" */ > else > do_false(); > > I dunno. That would probably be hard to represent via "git config > --type". And some callers probably do care about "auto" versus "true". It would work well for codepaths where computing the default value is cheap (or even possible). I think the point of using "auto" is to delay the decision as late as possible. E.g. in-core parsed config and attribute may still want to stay "auto", until we actually get our hands on the blob contents to see if it is binary, until we know how heavily loaded the system is, until we know isatty(1), etc. Some are cheap to compute in advance, some are expensive and impossible until we meet the data. So I still think the canonical use pattern for the "auto" thing is is_frotz = git_parse_bool_or_auto(value); ... arbitrary number of things can happen here ... the above may even be done in a git_config() ... callback, and is_frotz may not even be used. if (is_frotz == AUTO) is_frotz = auto_detect_frotz(); if (is_frotz) ...; /* do the frotz thing */ else ...; /* do the non-frotz thing */ > It also feels funny calling this "tristate". Aren't there other > tristates we could have besides "auto"? The command-line option is > bool-or-auto, which is descriptive. Should this use a similar name? I like that bool-or-auto name very much.
