Marco Stornelli <marco.stornelli@xxxxxxxxx> writes: > 2012/9/4 Junio C Hamano <gitster@xxxxxxxxx>: > >> I would expect, at least when you are responding to an existing >> message, some of them are filled already (and if so, I think appp.sh >> wants to know exactly how, for example, has RFC2047 quoting already >> applied, or are we supposed to write in UTF-8 and let Thunderbird >> massage the contents when we give the file back to it?), and also >> there would appear In-Reply-To: field already filled (possibly there >> may be References: as well). > > Message reply is out of scope of my patch. The goal here is send a > patch, so the execution flow is to open a new message, > clik on external editor (configured properly), select patch file and > send. It was the scope of the old script and it is the scope of my > patch. I certainly can understand that you updated the script for that use case and that use case only, but given that the original tries very hard to preserve: - what was in $HEADERS (by only replacing Subject); - the recipients CC'ed in $HEADERS (by grabbing them into $CCS); and - the body of the message in $BODY (i.e. what came after $SEP), I find it hard to believe that it was meant to work on a freshly created empty message and nothing else. If people were depending on the recipients listed on Cc that are taken from $1 to be preserved, your patch will introduce a regression for them, no? -- 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