Am 09.10.2012 21:45, schrieb Junio C Hamano:
> Jan H. Schönherr <> writes:
>> +test_expect_failure 'additional command line cc (rfc822)' '
>> +
>> +    git config --replace-all format.headers "Cc: R E Cipient 
>> <>" &&
>>      git format-patch --cc="S. E. Cipient <>" --stdout 
>> master..side | sed -e "/^\$/q" >patch5 &&
>> -    grep "^Cc: R. E. Cipient <>,\$" patch5 &&
>> -    grep "^ *S. E. Cipient <>\$" patch5
>> +    grep "^Cc: R E Cipient <>,\$" patch5 &&
>> +    grep "^ *"S. E. Cipient" <>\$" patch5
> Hrm.
> As we are not in the business of parsing out whatever junk given
> with --cc or --recipient from the command line or configuration, but
> are merely parroting them to the output stream, isn't this a
> user-error in the test that gives --cc='S. E. Cipient <>'
> instead of giving --cc='"S. E. Cipient" <>'?  Same comment
> on the new 'expect-failure' tests.

Originally, I just wanted to emphasize, that --to and --cc are
currently handled differently than in git-send-email, where
all this quoting/encoding is done.

And it is much more convenient to add
        --cc 'Jan H. Schönherr <...>'
        --cc '=?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= <...>'

Even more, since I would expect git to correctly handle
addresses given in a format that is also used elsewhere
within git.

However, I agree that we are not responsible to check/quote/encode
anything when the user supplies whole headers (though we probably

But if I cannot convince you, I'll just drop this patch. :)

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to