Is there some way to suppress Cc email only to stable?

> I need to be able to put the following Cc in a git commit:
>
> Cc: <stable@vger.kernel.org>
>
> Yet I cannot allow git-send-email to actually send email to that address,
> lest I get an automated nastygram in response.  I found the --to-cmd=
> option to git-send-email, but it looks to only add email addresses, never
> delete them.  I also found the --suppress-cc= option to git-send-email,
> but it appears to suppress all Cc emails, not just selected ones.
>
> One approach that occurred to me is to hand-edit the files produced
> by git-format-patch, removing stable@vger.kernel.org entirely prior to
> using git-send-email.  However, this is a bit error-prone.  Yes, I could
> script it, but with my luck, I will eventually end up having my script
> mangle some patch, for example to the Linux kernel's MAINTAINERS file.
> Furthermore, this approach means that people reviewing the patches
> cannot see the Cc stable entries (though I could presumably comment them
> out somehow).
>
> Another approach is to add the stable Ccs just before doing the pull
> request, by my upstream maintainer is not fond of that approach.  Nor am
> I, as it would be all to easy to forget to add the stable Ccs.  Or to
> get them wrong.
>
> I can't be the only person wanting to do something like this.  So is
> there some git option that I am missing here?

> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:
> 
> > I need to be able to put the following Cc in a git commit:
> >
> > Cc: <stable@vger.kernel.org>
> >
> > Yet I cannot allow git-send-email to actually send email to that address,
> > lest I get an automated nastygram in response.  I found the --to-cmd=
> > option to git-send-email, but it looks to only add email addresses, never
> > delete them.  I also found the --suppress-cc= option to git-send-email,
> > but it appears to suppress all Cc emails, not just selected ones.
> >
> > One approach that occurred to me is to hand-edit the files produced
> > by git-format-patch, removing stable@vger.kernel.org entirely prior to
> > using git-send-email.  However, this is a bit error-prone.  Yes, I could
> > script it, but with my luck, I will eventually end up having my script
> > mangle some patch, for example to the Linux kernel's MAINTAINERS file.
> > Furthermore, this approach means that people reviewing the patches
> > cannot see the Cc stable entries (though I could presumably comment them
> > out somehow).
> >
> > Another approach is to add the stable Ccs just before doing the pull
> > request, by my upstream maintainer is not fond of that approach.  Nor am
> > I, as it would be all to easy to forget to add the stable Ccs.  Or to
> > get them wrong.
> >
> > I can't be the only person wanting to do something like this.  So is
> > there some git option that I am missing here?
> 
> No, I do not think we have a way to blacklist certain recipient
> addresses from getting passed to the MTA, and I do not object to
> addition of such a mechanism if there is a valid need to do so.
> 
> It feels a bit too convoluted to say "Cc: to this address" in the
> log message and then "nonono, I do not want to send there", though.
> Why do you want to have Cc: in the log message if you do not want to
> send e-mail to that address in the first place?  Allowing the
> behaviour you are asking for would mean that those who see that the
> commit appeared on a branch would not be able to assume that the
> patch has already been sent to the stable review address, no?

> On Mon, Feb 09, 2015 at 12:57:11PM -0800, Junio C Hamano wrote:
>> No, I do not think we have a way to blacklist certain recipient
>> addresses from getting passed to the MTA, and I do not object to
>> addition of such a mechanism if there is a valid need to do so.
>> 
>> It feels a bit too convoluted to say "Cc: to this address" in the
>> log message and then "nonono, I do not want to send there", though.
>> Why do you want to have Cc: in the log message if you do not want to
>> send e-mail to that address in the first place?  Allowing the
>> behaviour you are asking for would mean that those who see that the
>> commit appeared on a branch would not be able to assume that the
>> patch has already been sent to the stable review address, no?
>
> I could see where it might seem a bit strange.  ;-)
>
> The reason behind this is that you are not supposed to actually send
> email to the stable lists until after the patch has been accepted into
> mainline.  One way to make this work is of course to leave the stable
> Cc tags out of the commit log, and to manually send an email when the
> commit has been accepted.  However, this is subject to human error,
> and more specifically in this case, -my- human error.
>
> Hence the desire to have a Cc that doesn't actually send any email,
> but that is visible in mainline for the benefit of the scripts that
> handle the stable workflow.

> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:
> 
> > On Mon, Feb 09, 2015 at 12:57:11PM -0800, Junio C Hamano wrote:
> >> No, I do not think we have a way to blacklist certain recipient
> >> addresses from getting passed to the MTA, and I do not object to
> >> addition of such a mechanism if there is a valid need to do so.
> >> 
> >> It feels a bit too convoluted to say "Cc: to this address" in the
> >> log message and then "nonono, I do not want to send there", though.
> >> Why do you want to have Cc: in the log message if you do not want to
> >> send e-mail to that address in the first place?  Allowing the
> >> behaviour you are asking for would mean that those who see that the
> >> commit appeared on a branch would not be able to assume that the
> >> patch has already been sent to the stable review address, no?
> >
> > I could see where it might seem a bit strange.  ;-)
> >
> > The reason behind this is that you are not supposed to actually send
> > email to the stable lists until after the patch has been accepted into
> > mainline.  One way to make this work is of course to leave the stable
> > Cc tags out of the commit log, and to manually send an email when the
> > commit has been accepted.  However, this is subject to human error,
> > and more specifically in this case, -my- human error.
> >
> > Hence the desire to have a Cc that doesn't actually send any email,
> > but that is visible in mainline for the benefit of the scripts that
> > handle the stable workflow.
> 
> So a configuration variable that you can set once and forget, e.g.
> 
>     [sendemail]
> 	blacklistedRecipients = stable@vger.kernel.org
> 
> would not cut it, as you would _later_ want to send the e-mail once
> the commit hits the mainline.  Am I reading you correctly?

>> > Hence the desire to have a Cc that doesn't actually send any email,
>> > but that is visible in mainline for the benefit of the scripts that
>> > handle the stable workflow.
>> 
>> So a configuration variable that you can set once and forget, e.g.
>> 
>>     [sendemail]
>> 	blacklistedRecipients = stable@vger.kernel.org
>> 
>> would not cut it, as you would _later_ want to send the e-mail once
>> the commit hits the mainline.  Am I reading you correctly?
>
> This would actually work for me.  Once the patch is accepted into
> mainline, I am done with it.  So I should -never- send email to
> stable@vger.kernel.org, unless I am doing so manually, for example because
> I forgot to add the stable tag to a given commit.  But in that case,
> I would just use mutt to forward the patch to stable@vger.kernel.org,
> and git would not be involved.

> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:
> 
> >> > Hence the desire to have a Cc that doesn't actually send any email,
> >> > but that is visible in mainline for the benefit of the scripts that
> >> > handle the stable workflow.
> >> 
> >> So a configuration variable that you can set once and forget, e.g.
> >> 
> >>     [sendemail]
> >> 	blacklistedRecipients = stable@vger.kernel.org
> >> 
> >> would not cut it, as you would _later_ want to send the e-mail once
> >> the commit hits the mainline.  Am I reading you correctly?
> >
> > This would actually work for me.  Once the patch is accepted into
> > mainline, I am done with it.  So I should -never- send email to
> > stable@vger.kernel.org, unless I am doing so manually, for example because
> > I forgot to add the stable tag to a given commit.  But in that case,
> > I would just use mutt to forward the patch to stable@vger.kernel.org,
> > and git would not be involved.
> 
> OK, thanks, we have a workable design to let us move forward, then.
> 
> Gits, any takers?

> Hi,
> 
> Paul E. McKenney wrote:
> 
> > Cc: <stable@vger.kernel.org>
> >
> > Yet I cannot allow git-send-email to actually send email to that address,
> > lest I get an automated nastygram in response.
> 
> Interesting.  Last time this came up, the result seemed to be
> different[*].

> Thanks,
> Jonathan
> 
> [*] http://thread.gmane.org/gmane.comp.version-control.git/178926/focus=178929
> 

> On Mon, Feb 09, 2015 at 01:53:50PM -0800, Jonathan Nieder wrote:
> > Hi,
> > 
> > Paul E. McKenney wrote:
> > 
> > > Cc: <stable@vger.kernel.org>
> > >
> > > Yet I cannot allow git-send-email to actually send email to that address,
> > > lest I get an automated nastygram in response.
> > 
> > Interesting.  Last time this came up, the result seemed to be
> > different[*].
> 
> Hmmm...  Greg KH didn't say there were no automated nastygrams, just
> that he wasn't worried about it.
> 
> I can try it on the next to-be-backported commit and see what happens.

> On Mon, Feb 09, 2015 at 03:35:37PM -0800, Paul E. McKenney wrote:
> > On Mon, Feb 09, 2015 at 01:53:50PM -0800, Jonathan Nieder wrote:
> > > Hi,
> > > 
> > > Paul E. McKenney wrote:
> > > 
> > > > Cc: <stable@vger.kernel.org>
> > > >
> > > > Yet I cannot allow git-send-email to actually send email to that address,
> > > > lest I get an automated nastygram in response.
> > > 
> > > Interesting.  Last time this came up, the result seemed to be
> > > different[*].
> > 
> > Hmmm...  Greg KH didn't say there were no automated nastygrams, just
> > that he wasn't worried about it.
> > 
> > I can try it on the next to-be-backported commit and see what happens.
> 
> There are no "automated" nastygrams, it's a "hit this key to send out
> this form message" I have in my email client.
> 
> The only time it triggers a false-positive is when I haven't had enough
> coffee in the morning, which is what happened recently with a patch from
> John Stultz.  If I've sent you that message incorrectly, I'm sorry,
> please let me know.

> Again, any patch cc:ed to stable that has a stable mark on it in the
> signed-off-by area is fine, and it helps me to know to watch out for
> things when they hit Linus's tree, or most importantly, to notice if
> they somehow _don't_ hit his tree.  Again, some recent patches from John
> fall in to that category, they didn't make it into Linus's tree when
> they probably should have for 3.19, and now I need to scoop them up
> quickly when they finally do.  If I hadn't been cc:ed on them, I would
> not have noticed that.
> 
> Hope this helps explain things,