Re: body-CC-comment regression

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Feb 16, 2017, 18:16 UTC
Message-ID: <vpqlgt6hug6.fsf@anie.imag.fr>
In-Reply-To: <20170216174924.GB2625@localhost>

Johan Hovold <johan@kernel.org> writes:

Show 15 quoted lines

> Hi,
>
> I recently noticed that after an upgrade, git-send-email (2.10.2)
> started aborting when trying to send patches that had a linux-kernel
> stable-tag in its body. For example,
>
> 	Cc: <stable@vger.kernel.org>	# 4.4
>
> was now parsed as
>
> 	"stable@vger.kernel.org#4.4"
>
> which resulted in
>
> 	Died at /usr/libexec/git-core/git-send-email line 1332, <FIN> line 1.

This has changed in e3fdbcc8e1 (parse_mailboxes: accept extra text after <...> address, 2016-10-13), released v2.11.0 as you noticed:

Show 19 quoted lines

> The problem with the resulting fixes that are now in 2.11.1 is that
> git-send-email no longer discards the trailing comment but rather
> shoves it into the name after adding some random white space:
>
> 	"# 3 . 3 . x : 1b9508f : sched : Rate-limit newidle" <stable@vger.kernel.org>"
>
> This example is based on the example from
> Documentation/process/stable-kernel-rules.rst:
>
> 	Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
>
> and this format for stable-tags has been documented at least since 2009
> and 8e9b9362266d ("Doc/stable rules: add new cherry-pick logic"), and
> has been supported by git since 2012 and 831a488b76e0 ("git-send-email:
> remove garbage after email address") I believe.
>
> Can we please revert to the old behaviour of simply discarding such
> comments (from body-CC:s) or at least make it configurable through a
> configuration option?

The problem is that we now accept list of emails instead of just one email, so it's hard to define what "comments after the email", for example

Cc: <foo@example.com> # , <boz@example.com>

Is not accepted as two emails.

So, just stripping whatever comes after # before parsing the list of emails would change the behavior once more, and possibly break other user's flow. Dropping the garbage after the email while parsing is possible, but only when we use our in-house parser (and we currently use Perl's Mail::Address when available).

So, a proper fix is far from obvious, and unfortunately I won't have time to work on that, at least not before a while.

OTOH, the current behavior isn't that bad. It accepts the input, and extracts a valid email out of it. Just the display name is admitedly suboptimal ...

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