Marco Stornelli [off-list ref] writes:
2012/9/4 Junio C Hamano [off-list ref]:
quoted
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?
Il 04/09/2012 17:49, Junio C Hamano ha scritto:
Marco Stornelli [off-list ref] writes:
quoted
2012/9/4 Junio C Hamano [off-list ref]:
quoted
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?
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 get_maintainer.pl 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.
Marco