git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Matthieu Moy <git@matthieu-moy.fr>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] send-email: fix garbage removal after address
Date: Thu, 24 Aug 2017 13:32:19 -0700	[thread overview]
Message-ID: <xmqqk21svh9o.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170823102102.20120-1-git@matthieu-moy.fr> (Matthieu Moy's message of "Wed, 23 Aug 2017 12:21:01 +0200")

Matthieu Moy <git@matthieu-moy.fr> writes:

> This is a followup over 9d33439 (send-email: only allow one address
> per body tag, 2017-02-20). The first iteration did allow writting
>
>   Cc: <foo@example.com> # garbage
>
> but did so by matching the regex ([^>]*>?), i.e. stop after the first
> instance of '>'. However, it did not properly deal with
>
>   Cc: foo@example.com # garbage
>
> Fix this using a new function strip_garbage_one_address, which does
> essentially what the old ([^>]*>?) was doing, but dealing with more
> corner-cases. Since we've allowed
>
>   Cc: "Foo # Bar" <foobar@example.com>
>
> in previous versions, it makes sense to continue allowing it (but we
> still remove any garbage after it). OTOH, when an address is given
> without quoting, we just take the first word and ignore everything
> after.
>
> Signed-off-by: Matthieu Moy <git@matthieu-moy.fr>
> ---
> Also available as: https://github.com/git/git/pull/398
>
>  git-send-email.perl   | 26 ++++++++++++++++++++++++--
>  t/t9001-send-email.sh |  4 ++++
>  2 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index fa6526986e..33a69ffe5d 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1089,6 +1089,26 @@ sub sanitize_address {
>  
>  }
>  
> +sub strip_garbage_one_address {
> +	my ($addr) = @_;
> +	chomp $addr;
> +	if ($addr =~ /^(("[^"]*"|[^"<]*)? *<[^>]*>).*/) {
> +		# "Foo Bar" <foobar@example.com> [possibly garbage here]
> +		# Foo Bar <foobar@example.com> [possibly garbage here]
> +		return $1;
> +	}
> +	if ($addr =~ /^(<[^>]*>).*/) {
> +		# <foo@example.com> [possibly garbage here]
> +		# if garbage contains other addresses, they are ignored.
> +		return $1;
> +	}

Isn't this already covered by the first one, which allows an
optional "something", followed by an optional run of SPs, in front
of this exact pattern, so the case where the optional "something"
does not appear and the number of optional SP is zero would exactly
match the one this pattern is meant to cover.

> +	if ($addr =~ /^([^"#,\s]*)/) {
> +		# address without quoting: remove anything after the address
> +		return $1;
> +	}
> +	return $addr;
> +}

By the way, these three regexps smell like they were written
specifically to cover three cases you care about (perhaps the ones
in your proposed log message), but what will be our response when
somebody else comes next time to us and says that their favourite
formatting of "Cc:" line is not covered by these rules?  

Will we add yet another pattern?  Where will it end?  There will be
a point where we instead start telling them to update the convention
of their project so that it will be covered by one of the patterns
we have already developed, I would imagine.

So, from that point of view, I, with devil's advocate hat on, wonder
why we are not saying

	"Cc: s@k.org # cruft"?  Use "Cc: <s@k.org> # cruft" instead
	and you'd be fine.

right now, without this patch.

I do not _mind_ us trying to be extra nice for a while, and I
certainly do not mind _this_ particular patch that gives us a single
helper function that future "here is another way to spell cruft"
rules can go, but I feel that there should be some line that lets us
say that we've done enough.

Thanks.

  parent reply	other threads:[~2017-08-24 20:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-22 23:15 git send-email Cc with cruft not working as expected Jacob Keller
2017-08-22 23:18 ` Stefan Beller
2017-08-22 23:30   ` Jacob Keller
2017-08-22 23:36     ` Stefan Beller
2017-08-23 10:02       ` Matthieu Moy
2017-08-23 10:21         ` [RFC PATCH 1/2] send-email: fix garbage removal after address Matthieu Moy
2017-08-23 10:21           ` [RFC PATCH 2/2] send-email: don't use Mail::Address, even if available Matthieu Moy
2017-08-23 21:59           ` [RFC PATCH 1/2] send-email: fix garbage removal after address Jacob Keller
2017-08-24 20:32           ` Junio C Hamano [this message]
2017-08-25  9:11             ` Matthieu Moy
2017-08-25  9:11               ` [PATCH v2 " Matthieu Moy
2017-08-25  9:12                 ` [PATCH v2 2/2] send-email: don't use Mail::Address, even if available Matthieu Moy
2017-08-23 22:49         ` git send-email Cc with cruft not working as expected Jacob Keller

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=xmqqk21svh9o.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@matthieu-moy.fr \
    --cc=git@vger.kernel.org \
    /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).