On Mon, May 31, 2021 at 11:53:04AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > 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
Ah, OK. Thanks for clarifying.
> 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.
Right, it was the list one I was most puzzled by. But if we were already
conflating implicit-bool and the empty string, I think it's OK. I agree
that all of this is something that _shouldn't_ happen in the first
place, for well-formed config.
-Peff
