Am 09.10.2012 21:45, schrieb Junio C Hamano: > Jan H. Schönherr <schnhrr@xxxxxxxxxxxxxxx> writes: > >> +test_expect_failure 'additional command line cc (rfc822)' ' >> + >> + git config --replace-all format.headers "Cc: R E Cipient <rcipient@xxxxxxxxxxx>" && >> git format-patch --cc="S. E. Cipient <scipient@xxxxxxxxxxx>" --stdout master..side | sed -e "/^\$/q" >patch5 && >> - grep "^Cc: R. E. Cipient <rcipient@xxxxxxxxxxx>,\$" patch5 && >> - grep "^ *S. E. Cipient <scipient@xxxxxxxxxxx>\$" patch5 >> + grep "^Cc: R E Cipient <rcipient@xxxxxxxxxxx>,\$" patch5 && >> + grep "^ *"S. E. Cipient" <scipient@xxxxxxxxxxx>\$" 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 <a@xxxxxxx>' > instead of giving --cc='"S. E. Cipient" <a@xxxxxxx>'? 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html