Jonathan, Thanks for pointing that out. I tried to preserve the cclist per your observation. My newsreader is outlook express and my mail client is outlook. As a result, I can only preserve the entire cc list on actual emails in my inbox. So in this case Junio was preserved in the cclist because I was able to reply-to-all in outlook (not outlook express). (But I took him out manually because I don't want to annoy him.) If I reply to a message on the newsgroup that was not explicitly emailed to me, then only the newsgroup is cc'd and any extra-newsgroup cc list is lost. I can see the sender's original cc list in outlook express in a header box at the top of the message preview pane, but I can't copy it (not even with hilite-copy). So in those cases I can only reply to the sender and the newsgroup, not to the extra-newsgroup cc list. Outlook only allows: "reply to newsgroup and not anyone else, not even the sender" (aka Reply-Group), "reply only to the sender" (aka Reply), "reply to the sender and cc the newsgroup only" (aka Reply-All) There is no option to "reply to sender and preserve the sender's entire original cc list". Maybe I need a better newsreader. I like how outlook express keeps the threads grouped together by the parent thread so I can expand the thread or collapse it. I don't like that can't preserve the extra-newgroup cclist. I appreciate your help as this is my first newsgroup I've ever posted to, and I apologize for any bad-newsgroup-etiquette due to my ignorance. v/r, Neal -----Original Message----- From: Jonathan Nieder [mailto:jrnieder@xxxxxxxxx] Sent: Thursday, December 09, 2010 2:02 PM To: Neal Kreitzinger Cc: git@xxxxxxxxxxxxxxx; Junio C Hamano Subject: Re: Tonight's pushout Neal Kreitzinger wrote: > "prerelease freeze" is not in the git-workflows manpage. I'm interested in > how you-all do this because I use the git-workflows mangpage to help me > figure out my workflows. Can someone explain? See http://en.wikipedia.org/wiki/Freeze_(software_engineering) In git's incarnation of it, presumably the idea is that new features do not get merged to 'master' (while they still would be merged to 'pu' and perhaps 'next'). See also <http://sites.google.com/site/maintnotes/> for some direct discussion of the branches used by git.git. Hope that helps, Jonathan [1] [1] Unrelated note: please try to preserve the cc list in replies (i.e., "reply-to-all-by-mail" rather than "followup"). "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -- 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