Suppressing auto-cc for specific addresses

Suppressing auto-cc for specific addresses

[Daniel Mack]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

Hi,

I'm looking for a way to suppress certain Cc: fields that are normally 
automatically added for addresses mentioned in Cc: lines found in patches.

In particular, the kernel rules for marking patches for stable release 
inclusion wants users to add a "Cc: stable@kernel.org" line in the patch 
itself but to not actually send a copy of that patch to that address. It 
will be picked automatically once the patch was applied upstream.

I couldn't find a proper way to do that with git send-email, so I dare 
to come up with a patch proposal. Is that acceptable or is there any 
better way (which I'm not aware about) to achive this?



Thanks,
Daniel

[-- Attachment #2: 0001-send-email-Allow-email-addresses-and-domains-as-supp.patch --]
[-- Type: text/plain, Size: 2899 bytes --]

From f1a17a4fbc0373283696cb560afff3afa05c2e8f Mon Sep 17 00:00:00 2001
From: Daniel Mack <zonque@gmail.com>
Date: Sun, 7 Aug 2011 22:16:00 +0200
Subject: [PATCH] send-email: Allow email addresses and domains as
 --suppress-cc options

Signed-off-by: Daniel Mack <zonque@gmail.com>
---
 Documentation/git-send-email.txt |   10 +++++++---
 git-send-email.perl              |   12 +++++++++++-
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 327233c..5966abb 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -233,9 +233,9 @@ Automating
 	cc list. Default is the value of 'sendemail.signedoffbycc' configuration
 	value; if that is unspecified, default to --signed-off-by-cc.
 
---suppress-cc=<category>::
-	Specify an additional category of recipients to suppress the
-	auto-cc of:
+--suppress-cc=<category|address|domain>::
+	Specify an additional category, email address or domain of recipients
+	to suppress the auto-cc for. Possible categories are:
 +
 --
 - 'author' will avoid including the patch author
@@ -251,6 +251,10 @@ Automating
 - 'all' will suppress all auto cc values.
 --
 +
+If a full email address is given, auto-cc will be suppressed for this particular
+address. This also works for entire domains if the parameter starts with the '@'
+sign. All email addresses in that domain will hence be ignored by auto-cc.
++
 Default is the value of 'sendemail.suppresscc' configuration value; if
 that is unspecified, default to 'self' if --suppress-from is
 specified, as well as 'body' if --no-signed-off-cc is specified.
diff --git a/git-send-email.perl b/git-send-email.perl
index 98ab33a..22813e5 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -374,7 +374,7 @@ my(%suppress_cc);
 if (@suppress_cc) {
 	foreach my $entry (@suppress_cc) {
 		die "Unknown --suppress-cc field: '$entry'\n"
-			unless $entry =~ /^(?:all|cccmd|cc|author|self|sob|body|bodycc)$/;
+			unless $entry =~ /^(?:all|cccmd|cc|author|self|sob|body|bodycc|.*@.*)$/;
 		$suppress_cc{$entry} = 1;
 	}
 }
@@ -1213,6 +1213,11 @@ foreach my $t (@files) {
 					} else {
 						next if ($suppress_cc{'cc'});
 					}
+					next if ($suppress_cc{$addr});
+					if ($addr =~ /^(.+)(@.+)$/) {
+						my $domain = $2;
+						next if $suppress_cc{$domain};
+					}
 					printf("(mbox) Adding cc: %s from line '%s'\n",
 						$addr, $_) unless $quiet;
 					push @cc, $addr;
@@ -1261,6 +1266,11 @@ foreach my $t (@files) {
 				next if $suppress_cc{'sob'} and $what =~ /Signed-off-by/i;
 				next if $suppress_cc{'bodycc'} and $what =~ /Cc/i;
 			}
+			next if ($suppress_cc{$c});
+			if ($c =~ /^(.+)(@.+)$/) {
+				my $domain = $2;
+				next if $suppress_cc{$domain};
+			}
 			push @cc, $c;
 			printf("(body) Adding cc: %s from line '%s'\n",
 				$c, $_) unless $quiet;
-- 
1.7.6

Re: Suppressing auto-cc for specific addresses

[Greg KH]

On Sun, Aug 07, 2011 at 10:20:26PM +0200, Daniel Mack wrote:
> Hi,
> 
> I'm looking for a way to suppress certain Cc: fields that are
> normally automatically added for addresses mentioned in Cc: lines
> found in patches.
> 
> In particular, the kernel rules for marking patches for stable
> release inclusion wants users to add a "Cc: stable@kernel.org" line
> in the patch itself but to not actually send a copy of that patch to
> that address. It will be picked automatically once the patch was
> applied upstream.

There is no "rule" that says you can not send a copy of the patch to
stable@kernel.org, in fact that happens a lot and is fine and I have no
problem with that at all.

So please don't feel that you have to do anything different here with
git to properly follow the stable kernel rules, there should not be any
need.

thanks,

greg k-h

Re: Suppressing auto-cc for specific addresses

[Daniel Mack]

On Mon, Aug 8, 2011 at 1:46 AM, Greg KH <greg@kroah.com> wrote:
> On Sun, Aug 07, 2011 at 10:20:26PM +0200, Daniel Mack wrote:
>> I'm looking for a way to suppress certain Cc: fields that are
>> normally automatically added for addresses mentioned in Cc: lines
>> found in patches.
>>
>> In particular, the kernel rules for marking patches for stable
>> release inclusion wants users to add a "Cc: stable@kernel.org" line
>> in the patch itself but to not actually send a copy of that patch to
>> that address. It will be picked automatically once the patch was
>> applied upstream.
>
> There is no "rule" that says you can not send a copy of the patch to
> stable@kernel.org, in fact that happens a lot and is fine and I have no
> problem with that at all.

Ok, thanks for explaining. In fact, I've done it that way ever since,
and never thought that there is any problem with it. But the topic
came up lately on the ALSA ML (and was continued off-list later), and
reading Documentation/stable_kernel_rules.txt again, I became aware of
the fact that sending it to stable@ is not actually necessary (while
at the same time, it doesn't seem to be frowned upon).

Anyway, I found it strange not have a way in git to achive this, and
maybe this new feature has other uses, too?


Thanks,
Daniel

Re: Suppressing auto-cc for specific addresses

[Daniel Mack]

On Mon, Aug 8, 2011 at 12:56 PM, David Aguilar <davvid@gmail.com> wrote:
> git send-email has a --[no-]signed-off-by-cc option and configuration
> variable. --

I know, but that's not the point. It about having a certain address
metioned in a ^Cc: line inside the patch and suppress sending off
emails to that specific address. And --suppress-cc currently only
allows categories to be set, not addresses.


Daniel

Re: Suppressing auto-cc for specific addresses

[Jeff King]

On Mon, Aug 08, 2011 at 12:58:55PM +0200, Daniel Mack wrote:

> On Mon, Aug 8, 2011 at 12:56 PM, David Aguilar <davvid@gmail.com> wrote:
> > git send-email has a --[no-]signed-off-by-cc option and configuration
> > variable. --
> 
> I know, but that's not the point. It about having a certain address
> metioned in a ^Cc: line inside the patch and suppress sending off
> emails to that specific address. And --suppress-cc currently only
> allows categories to be set, not addresses.

I'm kind of confused why you would mark an address as "cc", but not cc
it. Wouldn't it make sense to call the header something else?

-Peff

Re: Suppressing auto-cc for specific addresses

[Daniel Mack]

On Mon, Aug 8, 2011 at 10:44 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Aug 08, 2011 at 12:58:55PM +0200, Daniel Mack wrote:
>
>> On Mon, Aug 8, 2011 at 12:56 PM, David Aguilar <davvid@gmail.com> wrote:
>> > git send-email has a --[no-]signed-off-by-cc option and configuration
>> > variable. --
>>
>> I know, but that's not the point. It about having a certain address
>> metioned in a ^Cc: line inside the patch and suppress sending off
>> emails to that specific address. And --suppress-cc currently only
>> allows categories to be set, not addresses.
>
> I'm kind of confused why you would mark an address as "cc", but not cc
> it. Wouldn't it make sense to call the header something else?

Valid point. Even though Greg doesn't have a problem with the current
procedure as it stands, I see a problem in marking things for "Cc:
stable@kernel.org" just as a search pattern once they hit the Linux
mainline tree. Particularily because as it will end up in the
recipient list with git send-email, stable@ will get all the
follow-ups and discussions when people blindly hit the Reply-to-all
button (which we tell them to do). I for one would add
stable@kernel.org to my .gitconfig and be done with it, without ever
thinking about it again.

It's really not a big thing, and we can drop this patch if anyone has
real objections, but as it doesn't break anything for existing use
cases and might help others, why not apply it?


Daniel

Re: Suppressing auto-cc for specific addresses

[Jonathan Nieder]

Jeff King wrote:

> I'm kind of confused why you would mark an address as "cc", but not cc
> it. Wouldn't it make sense to call the header something else?

Maybe the patch is a draft and he is seeking early feedback.  The
final version will be cc-ed to the indicated person later (and that's
part of what it is time to get feedback on).

Or maybe the Cc: line is from the original patch and he is using git
send-email to forward it without mangling.

Re: Suppressing auto-cc for specific addresses

[Greg KH]

On Mon, Aug 08, 2011 at 11:01:12PM +0200, Daniel Mack wrote:
> On Mon, Aug 8, 2011 at 10:44 PM, Jeff King <peff@peff.net> wrote:
> > On Mon, Aug 08, 2011 at 12:58:55PM +0200, Daniel Mack wrote:
> >
> >> On Mon, Aug 8, 2011 at 12:56 PM, David Aguilar <davvid@gmail.com> wrote:
> >> > git send-email has a --[no-]signed-off-by-cc option and configuration
> >> > variable. --
> >>
> >> I know, but that's not the point. It about having a certain address
> >> metioned in a ^Cc: line inside the patch and suppress sending off
> >> emails to that specific address. And --suppress-cc currently only
> >> allows categories to be set, not addresses.
> >
> > I'm kind of confused why you would mark an address as "cc", but not cc
> > it. Wouldn't it make sense to call the header something else?
> 
> Valid point. Even though Greg doesn't have a problem with the current
> procedure as it stands, I see a problem in marking things for "Cc:
> stable@kernel.org" just as a search pattern once they hit the Linux
> mainline tree. Particularily because as it will end up in the
> recipient list with git send-email, stable@ will get all the
> follow-ups and discussions when people blindly hit the Reply-to-all
> button (which we tell them to do). I for one would add
> stable@kernel.org to my .gitconfig and be done with it, without ever
> thinking about it again.

No, that's a good thing, as the stable tree maintainer, I _want_ to see
that discussion to verify that this patch really is something that
should be applied to a stable kernel tree.

Lots of patches have originally been tagged in this manner, added to the
git tree, yet in discussion threads afterward, it's been determined that
this should not go to the stable tree.  If I hadn't been on that thread
in the first place, I would have missed that.

So again, I have no objection to cc: stable@kernel.org, and in fact,
encourage it.  Don't worry, I can handle the email load :)

thanks,

greg k-h

Re: Suppressing auto-cc for specific addresses

[Jonathan Nieder]

(+cc: some send-email people)
Hi,

Daniel Mack wrote:

> I'm looking for a way to suppress certain Cc: fields that are normally
> automatically added for addresses mentioned in Cc: lines found in patches.

Makes sense.  Could you please add a quick commit message, following
the guidelines in Documentation/SubmittingPatches (i.e., explaining
the problem this intends to solve and justifying how it is solved)?

Patch left untrimmed for Joe and Ævar's convenience.  Thanks and hope
that helps.

> From: Daniel Mack <zonque@gmail.com>
> Date: Sun, 7 Aug 2011 22:16:00 +0200
> Subject: [PATCH] send-email: Allow email addresses and domains as
>  --suppress-cc options
> 
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> ---
>  Documentation/git-send-email.txt |   10 +++++++---
>  git-send-email.perl              |   12 +++++++++++-
>  2 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
> index 327233c..5966abb 100644
> --- a/Documentation/git-send-email.txt
> +++ b/Documentation/git-send-email.txt
> @@ -233,9 +233,9 @@ Automating
>  	cc list. Default is the value of 'sendemail.signedoffbycc' configuration
>  	value; if that is unspecified, default to --signed-off-by-cc.
>  
> ---suppress-cc=<category>::
> -	Specify an additional category of recipients to suppress the
> -	auto-cc of:
> +--suppress-cc=<category|address|domain>::
> +	Specify an additional category, email address or domain of recipients
> +	to suppress the auto-cc for. Possible categories are:
>  +
>  --
>  - 'author' will avoid including the patch author
> @@ -251,6 +251,10 @@ Automating
>  - 'all' will suppress all auto cc values.
>  --
>  +
> +If a full email address is given, auto-cc will be suppressed for this particular
> +address. This also works for entire domains if the parameter starts with the '@'
> +sign. All email addresses in that domain will hence be ignored by auto-cc.
> ++
>  Default is the value of 'sendemail.suppresscc' configuration value; if
>  that is unspecified, default to 'self' if --suppress-from is
>  specified, as well as 'body' if --no-signed-off-cc is specified.
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 98ab33a..22813e5 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -374,7 +374,7 @@ my(%suppress_cc);
>  if (@suppress_cc) {
>  	foreach my $entry (@suppress_cc) {
>  		die "Unknown --suppress-cc field: '$entry'\n"
> -			unless $entry =~ /^(?:all|cccmd|cc|author|self|sob|body|bodycc)$/;
> +			unless $entry =~ /^(?:all|cccmd|cc|author|self|sob|body|bodycc|.*@.*)$/;
>  		$suppress_cc{$entry} = 1;
>  	}
>  }
> @@ -1213,6 +1213,11 @@ foreach my $t (@files) {
>  					} else {
>  						next if ($suppress_cc{'cc'});
>  					}
> +					next if ($suppress_cc{$addr});
> +					if ($addr =~ /^(.+)(@.+)$/) {
> +						my $domain = $2;
> +						next if $suppress_cc{$domain};
> +					}
>  					printf("(mbox) Adding cc: %s from line '%s'\n",
>  						$addr, $_) unless $quiet;
>  					push @cc, $addr;
> @@ -1261,6 +1266,11 @@ foreach my $t (@files) {
>  				next if $suppress_cc{'sob'} and $what =~ /Signed-off-by/i;
>  				next if $suppress_cc{'bodycc'} and $what =~ /Cc/i;
>  			}
> +			next if ($suppress_cc{$c});
> +			if ($c =~ /^(.+)(@.+)$/) {
> +				my $domain = $2;
> +				next if $suppress_cc{$domain};
> +			}
>  			push @cc, $c;
>  			printf("(body) Adding cc: %s from line '%s'\n",
>  				$c, $_) unless $quiet;
> -- 
> 1.7.6

Re: Suppressing auto-cc for specific addresses

[Joe Perches]

On Mon, 2011-08-08 at 23:17 +0200, Jonathan Nieder wrote:
> (+cc: some send-email people)
> Daniel Mack wrote:
> > I'm looking for a way to suppress certain Cc: fields that are normally
> > automatically added for addresses mentioned in Cc: lines found in patches.
> Makes sense.  Could you please add a quick commit message, following
> the guidelines in Documentation/SubmittingPatches (i.e., explaining
> the problem this intends to solve and justifying how it is solved)?

It seems an odd use case to me.
Why are these added addresses undesired?

Also this does not work for cccmd addresses.
You'll need to add similar logic to recipient_cmd
uses.

cheers, Joe

Re: Suppressing auto-cc for specific addresses

[Jeff King]

On Mon, Aug 08, 2011 at 11:07:14PM +0200, Jonathan Nieder wrote:

> > I'm kind of confused why you would mark an address as "cc", but not cc
> > it. Wouldn't it make sense to call the header something else?
> 
> Maybe the patch is a draft and he is seeking early feedback.  The
> final version will be cc-ed to the indicated person later (and that's
> part of what it is time to get feedback on).

I suspect in that workflow, you would use --suppress-cc=all, and then
just address it to whomever you are getting feedback from.

> Or maybe the Cc: line is from the original patch and he is using git
> send-email to forward it without mangling.

In that case, shouldn't the cc either be respected (since the original
patch author wanted it so), or stripped (if the patch no longer has
anything to do with that cc).


Still, we are only guessing at possible workflows here. I don't have a
problem with the idea of per-address suppression; it makes git more
flexible and doesn't hurt people who don't need the flexibility.

I was more objecting to it as a solution to a workflow that is "we want
a unique tag in the commit, so we called it 'cc', but don't want people
to actually 'cc' it". That's just wrong and silly. But it turns out that
isn't happening here, anyway.

-Peff

Re: Suppressing auto-cc for specific addresses

[Daniel Mack]

On Tue, Aug 9, 2011 at 9:01 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Aug 08, 2011 at 11:07:14PM +0200, Jonathan Nieder wrote:
>
>> > I'm kind of confused why you would mark an address as "cc", but not cc
>> > it. Wouldn't it make sense to call the header something else?
>>
>> Maybe the patch is a draft and he is seeking early feedback.  The
>> final version will be cc-ed to the indicated person later (and that's
>> part of what it is time to get feedback on).
>
> I suspect in that workflow, you would use --suppress-cc=all, and then
> just address it to whomever you are getting feedback from.
>
>> Or maybe the Cc: line is from the original patch and he is using git
>> send-email to forward it without mangling.
>
> In that case, shouldn't the cc either be respected (since the original
> patch author wanted it so), or stripped (if the patch no longer has
> anything to do with that cc).
>
>
> Still, we are only guessing at possible workflows here. I don't have a
> problem with the idea of per-address suppression; it makes git more
> flexible and doesn't hurt people who don't need the flexibility.
>
> I was more objecting to it as a solution to a workflow that is "we want
> a unique tag in the commit, so we called it 'cc', but don't want people
> to actually 'cc' it". That's just wrong and silly. But it turns out that
> isn't happening here, anyway.

Right. I thought I might fix something here to improve a widely
anticipated workflow, but as it turns out, it's not actually needed. I
don't personally have any other use for this feature, so I don't care
much whether it will be applied eventually. Except for the fact that
it would be my first contribution to git, of course ;)

So - up to you to decide.


Thanks,
Daniel