Subject: Re: Local unset override global options

From: Jakub Narebski <[email-masked]>
Date: Mon, 12 Apr 2010 23:07:21 +0200

Junio C Hamano wrote:
> Jakub Narebski <[email-masked]> writes:
> 
> > Junio C Hamano wrote:
> >> Jakub Narebski <[email-masked]> writes:
> >> 
> >> > How does special case of no value, i.e.
> >> >
> >> >    [sendemail]
> >> >         smtpuser
> >> 
> >> That is not a special case; that is "boolean true".
> >
> > Well, it is "boolean true" *if* git-config is used with '--bool'.
> >
> > If git-send-email.perl used "git config -l -z" to read all its config 
> > variables at once into hash, like gitweb.perl does in the 
> > git_parse_project_config() subroutine, it would be able to distinguish 
> > between those the case of no value:
> >
> >     [sendemail]
> >          smtpuser
> 
> If sendemail is ever re-written in C and use git_config() API, the above
> will become boolean.

Isn't this only for git_config_bool and the like... oh, I see that
git_config_string does not consider no value case proper string value,
and warns that it is suitable only for boolean variables:

   if (!value)
                return config_error_nonbool(var);

> Besides, even if you are sticking to sendemail.perl 
> forever, you are still inventing another convention that "boolean true
> means no I don't want it".  And it is clearly a lot less intuitive than
> "empty means no I don't want it", isn't it?

True, after thinking a bit about this using no value to unset is 
a horrible, horrible hack.  git-send-email should be corrected to not
only check that there is value from config or command line option, but
also that it is sane (i.e. non-empty, or simply true-ish if we say
that smtpuser = "0" is not something we need to worry about supporting).

About ORIGINAL problem: I think it can be done by setting different
identities, and just switching them using sendemail.identity; for some
of those identities sendemail.<identity>.smtpuser can be not set.

-- 
Jakub Narebski
Poland