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@xxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxx" 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@xxxxxxxxxx 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@xxxxxxxxxx, and in fact, encourage it. Don't worry, I can handle the email load :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html