Il 04/09/2012 17:49, Junio C Hamano ha scritto:
Marco Stornelli <> writes:

2012/9/4 Junio C Hamano <>:

I would expect, at least when you are responding to an existing
message, some of them are filled already (and if so, I think
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

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?

I think all the process is different. Current script rely on the user to fill Cc: and To: in message composition window, it does a union of what found in commit message as signed-off-by (adding own address in cc?!) and Cc (usually not filled in the commit message and we should even count acked-by, tested-by and so on). My vision of things: the user can create a patch *already* with all information using --to and --cc. If you want to add optional addresses, you can of course add them in the composition window. In addition, with this approach is really easy to use external script as of linux kernel, load the patch and send, really easy. So I don't think it's a regression, it's only a change in the work flow.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to