Re: [PATCH 1/1] send-email: fix transferencoding config option
- From
Heinrich Schuchardt <xypron.glpk@gmx.de>
- Date
- Apr 9, 2019, 23:06 UTC
- Message-ID
- <bd431817-3c47-c05c-5a92-b26eb2b25d4d@gmx.de>
- In-Reply-To
- <20190409225531.GI12419@genre.crustytoothpaste.net>
On 4/10/19 12:55 AM, brian m. carlson wrote:
Show 18 quoted lines
> On Tue, Apr 09, 2019 at 09:27:33PM +0200, Heinrich Schuchardt wrote: >> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt >> index 1afe9fc858..884e776add 100644 >> --- a/Documentation/git-send-email.txt >> +++ b/Documentation/git-send-email.txt >> @@ -146,7 +146,7 @@ Note that no attempts whatsoever are made to validate the encoding. >> even more opaque. auto will use 8bit when possible, and quoted-printable >> otherwise. >> + >> -Default is the value of the `sendemail.transferEncoding` configuration >> +Default is the value of the `sendemail.transferencoding` configuration >> value; if that is unspecified, default to `auto`. > > In Git, two-part config settings are case-insensitive. We traditionally > write them in lower camel case because it's easier for people to read. > Git will canonicalize the values when "git config" runs. > > So I don't think we should change this.
Thanks for the hint.
Show 28 quoted lines
>
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index 8200d58cdc..0e23193939 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -239,7 +239,7 @@ sub do_edit {
>> my (@suppress_cc);
>> my ($auto_8bit_encoding);
>> my ($compose_encoding);
>> -my $target_xfer_encoding = 'auto';
>> +my ($target_xfer_encoding);
>>
>> my ($debug_net_smtp) = 0; # Net::SMTP, see send_message()
>>
>> @@ -446,6 +446,8 @@ sub read_config {
>> $smtp_encryption = 'ssl';
>> }
>> }
>> +
>> + $target_xfer_encoding = 'auto' unless (defined $target_xfer_encoding);
>> }
>>
>> # read configuration from [sendemail "$identity"], fall back on [sendemail]
>
> Thanks for fixing this. I didn't realize that we only set values if the
> variable holding them is undef. Would you mind adding a test for this
> case so we won't regress it in the future?
>Nice challenge for my first patch for git :) I will give it a try.
Best regards
Heinrich