Am 09.10.2012 21:45, schrieb Junio C Hamano:
> Jan H. Schönherr <[email protected]> writes:
>
>> +test_expect_failure 'additional command line cc (rfc822)' '
>> +
>> + git config --replace-all format.headers "Cc: R E Cipient
>> <[email protected]>" &&
>> git format-patch --cc="S. E. Cipient <[email protected]>" --stdout
>> master..side | sed -e "/^\$/q" >patch5 &&
>> - grep "^Cc: R. E. Cipient <[email protected]>,\$" patch5 &&
>> - grep "^ *S. E. Cipient <[email protected]>\$" patch5
>> + grep "^Cc: R E Cipient <[email protected]>,\$" patch5 &&
>> + grep "^ *"S. E. Cipient" <[email protected]>\$" 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 <[email protected]>'
> instead of giving --cc='"S. E. Cipient" <[email protected]>'? 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 <...>'
than
--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
could).
But if I cannot convince you, I'll just drop this patch. :)
Regards
Jan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
