git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 5/5] format-patch: tests: check rfc822+rfc2047 in to+cc headers

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 10, 2012, 17:02 UTC
Message-ID
<7vhaq2clb3.fsf@alter.siamese.dyndns.org>
In-Reply-To
<50755170.1080205@cs.tu-berlin.de>
"Jan H. Schönherr" <schnhrr@cs.tu-berlin.de> writes:
Show 40 quoted lines
> Am 09.10.2012 21:45, schrieb Junio C Hamano:
>> Jan H. Schönherr <schnhrr@cs.tu-berlin.de> writes:
>> 
>>> +test_expect_failure 'additional command line cc (rfc822)' '
>>> +
>>> +	git config --replace-all format.headers "Cc: R E Cipient <rcipient@example.com>" &&
>>>  	git format-patch --cc="S. E. Cipient <scipient@example.com>" --stdout master..side | sed -e "/^\$/q" >patch5 &&
>>> -	grep "^Cc: R. E. Cipient <rcipient@example.com>,\$" patch5 &&
>>> -	grep "^ *S. E. Cipient <scipient@example.com>\$" patch5
>>> +	grep "^Cc: R E Cipient <rcipient@example.com>,\$" patch5 &&
>>> +	grep "^ *"S. E. Cipient" <scipient@example.com>\$" 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@ddre.ss>'
>> instead of giving --cc='"S. E. Cipient" <a@ddre.ss>'?  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. :)
It wasn't about convincing or not convincing me.

I couldn't read, just from "expect_failure" and "Do some checks for...", what the intention of the tests and the proposed future plans were.

If the proposed commit log message (or comments before these "expect_failure" tests) said something like this:

    "git send-email" historically did not parse the user supplied
    extra header values (e.g. --cc, --recipient) and just replayed
    them, but that forces users to add them in encoded form, e.g.
 	--cc '=?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= <...>'
    which is inconvenient. We would want to update send-email to
    accept human-readable
 	--cc 'Jan H. Schönherr <...>'
    and encode in the future.  Add test_expect_failure tests as a
    reminder.

that would have avoided such confusion, and even more importantly, made it easier for us to start discussion on the proposed future direction. I am personally on the fence.

Previous: Jan H. SchönherrNext: Jan H. Schönherr
Message 9 of 10 in “Cure some format-patch wrapping and encoding issues”
  1. 0/5 Cure some format-patch wrapping and encoding issuesJan H. Schönherr, Oct 8, 2012
  2. 1/5 format-patch: do not wrap non-rfc2047 headers too earlyJan H. Schönherr, Oct 8, 2012
  3. 2/5 format-patch: do not wrap rfc2047 encoded headers too lateJan H. Schönherr, Oct 8, 2012
  4. 3/5 format-patch: introduce helper function last_line_length()Jan H. Schönherr, Oct 8, 2012
  5. 4/5 format-patch: fix rfc2047 address encoding with respect to rfc822 specialsJan H. Schönherr, Oct 8, 2012
  6. 5/5 format-patch: tests: check rfc822+rfc2047 in to+cc headersJan H. Schönherr, Oct 8, 2012
  7. Jan H. SchönherrOct 10, 2012
  8. Jan H. SchönherrOct 10, 2012
  9. Junio C HamanoOct 10, 2012
  10. Jan H. SchönherrOct 10, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.