Jeff King [off-list ref] writes:
However, doing it right is kind of tricky due to rfc822 quoting, rfc2047
encoding, and handling non-ascii names correctly. Instead, this patch
series takes a different approach: it teaches format-patch to do the
transformation itself, so that it can be used by my script along with
any other non-send-email workflows that exist (e.g., git-imap-send
suffers from the same problem).
I think the original expectation when format-patch was done was to
use Sender: to identify you while keeping the author on From:, but
with the current world order to use in-body header, this addition
makes sense.
I wonder if we can lose some code from send-email then?
On Wed, Jul 03, 2013 at 01:58:22AM -0700, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
However, doing it right is kind of tricky due to rfc822 quoting, rfc2047
encoding, and handling non-ascii names correctly. Instead, this patch
series takes a different approach: it teaches format-patch to do the
transformation itself, so that it can be used by my script along with
any other non-send-email workflows that exist (e.g., git-imap-send
suffers from the same problem).
I think the original expectation when format-patch was done was to
use Sender: to identify you while keeping the author on From:, but
with the current world order to use in-body header, this addition
makes sense.
Yeah, I think using "Sender" would simply be too confusing, as most MUAs
show only the "From", and authors of patches do not necessarily know or
care about the mailing of their patch.
I wonder if we can lose some code from send-email then?
Potentially, as long as we default to "--from" to turn this feature on
all the time (otherwise we are breaking the existing "format-patch &&
send-email" workflow).
It may also confuse people who mark up the patches on disk before
running send-email. I don't know if people actually change the From
header there or not.
-Peff