Re: [PATCH 1/1] send-email: fix transferencoding config option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/9/19 11:58 PM, Jonathan Nieder wrote:
> (thanks for cc-ing bmc!)
> Hi,
>
> Heinrich Schuchardt wrote:
>
>> Subject: send-email: fix transferencoding config option
>
> nit: "fix" doesn't tell me what was broken and what you improved about
> it.  Here, I think you mean "respect transferencoding config option".
>
>> Since e67a228cd8a ("send-email: automatically determine transfer-encoding")
>> the value of sendmail.transferencoding is ignored because when parsing
>> the configuration $target_xfer_encoding is not initial anymore.
>
> nit: I was confused when first reading this, since I read "the
> configuration $target_xfer_encoding" as a single phrase.  A comma
> after "configuration" might help.
>
>> Instead of initializing variable $target_xfer_encoding on definition we
>> have to set it to the default value of 'auto' if is initial after parsing
>> the configuration files.
>
> run-on sentence.  I'm having trouble parsing this part.
>
> Can you start from the beginning and describe again what this does?
> In other words, tell me
>
> - What is the user-facing effect of the change?  What workflow is it
>   part of?

I am working with a repository which uses CRLF line endings. So when
sending patches I should use an appropriate encoding. There should be
two ways to do it:

- call git-send-email with --transfer-encoding base64
- git config --global sendmail.transferencoding base64

Unfortunately the latter method did not show the expected result. The
setting was simply ignored.

>
> - Any risks or complications?

None that I am aware of.

>
> - Any technical details that might be interesting to the later reader?

As I tried to explain above the setting is ignored because a variable is
initialized too early.

>
> - What does this allow me to do that I couldn't do before?

You can use a global setting for the transfer encoding.

>
> The code can speak for itself, so this should primarily focus on the
> intention behind the change.
>
> [...]
>> --- 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
>
> Unrelated change?
>
> [...]
>> --- 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);
>
> Makes sense.
>
> Is there a way to cover this in tests (t/t9001-send-email.sh) so we
> can avoid regressing again?

I will give it a try.

>
> The rest looks good.
>
> Thanks for noticing, and hope that helps,
> Jonathan
>
Thanks for reviewing.

Best regards

Heinrich




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux