Re: [PATCH v5 00/13] send-email: various optimizations to speed up by >2x

> > I guess here:
> >
> >>     @@ git-send-email.perl: sub read_config {
> >>      -			my @values = Git::config(@repo, $key);
> >>      -			next unless @values;
> >>      +			my @values = @{$known_keys->{$key}};
> >>     ++			@values = grep { defined } @values;
> >>       			next if $configured->{$setting}++;
> >>       			@$target = @values;
> >>       		}
> >>       		else {
> >>      -			my $v = Git::config(@repo, $key);
> >>     --			next unless defined $v;
> >>      +			my $v = $known_keys->{$key}->[0];
> >>     + 			next unless defined $v;
> >>       			next if $configured->{$setting}++;
> >>       			$$target = $v;
> >>     - 		}
> >
> > we'd ignore such undef values, whereas presumably before they'd have
> > triggered an error via Git::config(). I don't think it matters all that
> > much either way, though.
> 
> They didn't error before, they were treated the same as the empty
> string.
> 
> This is because Git.pm uses "git config --get" to retrieve them, but we
> now use "--list --null".
> 
> This ultimately comes down to a limitation of git-config's one-shot CLI
> interface. You get the empty string and zero exit code for both of:
> 
>     git -c foo.bar= config --get foo.bar
>     git -c foo.bar config --get foo.bar

> Ignoring them here for list values is technically a behavior change if
> we were treating this as a black box, but in reality we know that these
> could only conceivable be useful for the bool values, for list values
> like "list of e-mail addresses" it makes no sense to have that in a the
> middle of a list, and we were implicitly ignoring them anyway before
> when we processed the empty string.