git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: Junio C Hamano <gitster@pobox.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
	Jeff King <peff@peff.net>,
	Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>,
	Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr>,
	git@vger.kernel.org
Subject: Re: Formatting problem send_mail in version 2.10.0
Date: Thu, 13 Oct 2016 07:32:26 +0200	[thread overview]
Message-ID: <vpq1szkolud.fsf@anie.imag.fr> (raw)
In-Reply-To: <xmqqtwch2srj.fsf@gitster.mtv.corp.google.com> (Junio C. Hamano's message of "Wed, 12 Oct 2016 13:53:52 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> People write things like these
>
>     Cc: Stable <stable@vger.kernel.org> # 4.8
>     Cc: Stable <stable@vger.kernel.org> [4.8+]
>
> in the trailer part in the body of the message.  Are these lines
> meant to be usable if they appear as Cc: headers of an outgoing
> piece of e-mail as-is?

I think this is not the right question. The relevant one is: should
these lines be accepted by git and turned into something usable if they
appear as Cc: headers of an outgoing piece of e-mail?

I.e. "Be liberal in what you accept, and conservative in what you send".

If you have Mail::Address installed, this is already possible. With
pre-2.6, I did not re-test, but I think it was using the addresses
as-is, which probably worked but AFAICT created non-RCF-compliant
emails.

> "error: unable to extract a valid address from:" is followed by
>
>     Stable <stable@vger.kernel.org#4.8>
>     Stable <stable@vger.kernel.org[4.8+]>
>
> which is not ideal.

I'd actually even say "broken" ;-). If we decide to reject these, we
should at least give a sensible error message.

> If I were to issue a decree, I would say that people should stop
> suggesting to put RFC-bogus things on the Cc: line.  As you
> mentioned, things like:
>
>     Cc: Stable (4.8+) <stable@vger.kernel.org>
>     Cc: "Stable 4.8+" <stable@vger.kernel.org>
>
> are perfectly readable alternative that are still RFC-kosher.

I do support those, but if there's an established tradition of using
# ... trailer, then I don't think we should be the ones forcing it to
stop.

> Things may have appeared to work by accident, and things may still
> work by accident, depending on the vintage and availability of
> Mail::Address package (which seems to be the case), but it is not
> worth risking random breakages that depends on what other people
> use in the first place, no?

The "depending on the availability of Mail::Address" is what bothers me
most. Suppose we make a strong statement here that this # 4.8 should
stop. Then some users will listen to that statements, but others won't
read the thread, test with their own git that it works, and recommend it
to users for whom it doesn't.

> That is, even though people seem to expect "send-email --cc" to
> somehow be able to judge that " # 4.8" and " [4.8+]" are cruft not
> meant as part of a valid address, I do not think it is a realistic
> expectation.  How would it know "Cc: Stable <add@re.ss> 4.8, 4.9"
> has garbage " 4.8, 4.9" that needs to be stripped, while "Cc: Stable
> <add@re.ss> 4.8, torvalds@linux-foundation.org" has two valid
> addresses that need to be CC'ed and " 4.8" is the only thing that is
> unwanted?

We clearly can't guess, but we can be consistent with Mail::Address, so
that git's behavior depends less on its availability.

Patch follows doing that.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

  parent reply	other threads:[~2016-10-13  5:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-10 21:00 Formatting problem send_mail in version 2.10.0 Larry Finger
2016-10-10 21:48 ` Jeff King
2016-10-10 21:57   ` Jeff King
2016-10-10 23:35     ` Larry Finger
2016-10-10 23:43       ` Jeff King
2016-10-11  7:39     ` Matthieu Moy
2016-10-11 15:42       ` Larry Finger
2016-10-11 16:18         ` Matthieu Moy
2016-10-12  4:28           ` Larry Finger
2016-10-12  7:36             ` Matthieu Moy
2016-10-12 15:27               ` Larry Finger
2016-10-12 15:40                 ` Matthieu Moy
2016-10-12 15:40               ` Larry Finger
2016-10-12 15:45                 ` Matthieu Moy
2016-10-12 15:59                   ` Larry Finger
2016-10-12 20:53                   ` Junio C Hamano
2016-10-12 23:13                     ` Jeff King
2016-10-13  5:37                       ` Matthieu Moy
2016-10-13  5:47                         ` [PATCH] parse_mailboxes: accept extra text after <...> address Matthieu Moy
2016-10-13 15:33                       ` Formatting problem send_mail in version 2.10.0 Kevin Daudt
2016-10-13 16:05                         ` Matthieu Moy
2016-10-13  5:32                     ` Matthieu Moy [this message]
2016-10-14 17:04                       ` Junio C Hamano
2016-10-11 16:02       ` Jeff King

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=vpq1szkolud.fsf@anie.imag.fr \
    --to=matthieu.moy@grenoble-inp.fr \
    --cc=Larry.Finger@lwfinger.net \
    --cc=Mathieu.Lienard--Mayor@ensimag.imag.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=remi.lespinet@ensimag.grenoble-inp.fr \
    /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).