Suppressing auto-cc for specific addresses

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: [email protected]" 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.

Quoted 9 lines · Daniel Mack

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: [email protected]" 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 [email protected], in fact that happens a lot and is fine and I have no problem with that at all.

git send-email has a --[no-]signed-off-by-cc option and configuration variable. --

Quoted 2 lines · David Aguilar

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?

Quoted 2 lines

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.

Quoted 6 lines · Jonathan Nieder

Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 4 lines · Daniel Mack

Quoted 2 lines · David Aguilar

git send-email has a --[no-]signed-off-by-cc option and configuration variable. --

Quoted 4 lines

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?

Quoted 6 lines · Jeff King

Quoted 4 lines · Daniel Mack

Quoted 2 lines · David Aguilar

git send-email has a --[no-]signed-off-by-cc option and configuration variable. --

Quoted 7 lines

Quoted 4 lines

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:
[email protected]" 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 [email protected] to my .gitconfig and be done with it, without ever thinking about it again.

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.

From: Daniel Mack <[email protected]>
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 <[email protected]>

---
 Documentation/git-send-email.txt |   10 +++++++---
 git-send-email.perl              |   12 +++++++++++-
 2 files changed, 18 insertions(+), 4 deletions(-)

Documentation/git-send-email.txt +7 -3

index 327233c..5966abb 100644
@@ -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.

git-send-email.perl +11 -1

index 98ab33a..22813e5 100755
@@ -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;

Signature · 1 line

1.7.6

(+cc: some send-email people)

Quoted 2 lines · Daniel Mack

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)?