git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Jan H. Schönherr" <schnhrr@cs.tu-berlin.de>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [PATCH 5/5] format-patch: tests: check rfc822+rfc2047 in to+cc headers
Date: Wed, 10 Oct 2012 10:02:24 -0700	[thread overview]
Message-ID: <7vhaq2clb3.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <50755170.1080205@cs.tu-berlin.de> ("Jan H. Schönherr"'s message of "Wed, 10 Oct 2012 12:44:00 +0200")

"Jan H. Schönherr" <schnhrr@cs.tu-berlin.de> writes:

> 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.

  reply	other threads:[~2012-10-10 17:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-08 17:33 [PATCH 0/5] Cure some format-patch wrapping and encoding issues Jan H. Schönherr
2012-10-08 17:33 ` [PATCH 1/5] format-patch: do not wrap non-rfc2047 headers too early Jan H. Schönherr
2012-10-08 17:33 ` [PATCH 2/5] format-patch: do not wrap rfc2047 encoded headers too late Jan H. Schönherr
     [not found]   ` <7v7gqzfnpj.fsf@alter.siamese.dyndns.org>
2012-10-10  9:31     ` "Jan H. Schönherr"
2012-10-08 17:33 ` [PATCH 3/5] format-patch: introduce helper function last_line_length() Jan H. Schönherr
2012-10-08 17:33 ` [PATCH 4/5] format-patch: fix rfc2047 address encoding with respect to rfc822 specials Jan H. Schönherr
2012-10-08 17:33 ` [PATCH 5/5] format-patch: tests: check rfc822+rfc2047 in to+cc headers Jan H. Schönherr
     [not found]   ` <7v391nfmzn.fsf@alter.siamese.dyndns.org>
2012-10-10 10:44     ` "Jan H. Schönherr"
2012-10-10 17:02       ` Junio C Hamano [this message]
     [not found] ` <7vfw5nfoq9.fsf@alter.siamese.dyndns.org>
2012-10-10 10:49   ` [PATCH 0/5] Cure some format-patch wrapping and encoding issues "Jan H. Schönherr"

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vhaq2clb3.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=schnhrr@cs.tu-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).