Re: [PATCH] send-email: do not insert third header

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Stepan Kasal <kasal@ucw.cz> writes:
>
>> It is sometimes desirable to insert several header lines at the top of
>> the body, e.g., if From or Date differs from the mail header.
>> (Linus even recommends to use this second header for all kernel
>> submissions.)
>>
>> send-email has a minimal support for this; make sure it is not applied
>> when there is a second header already inserted in the patch file.
>
> I have a slight suspicion that you are reading the recommendation
> wrong.  We do not recommend to record these in-body headers in the
> message of the commit object (the recommendation is to prepend
> in-body headers to the message of the commit object when sending it
> out for review---it pretty much assumes that the underlying commit
> does not have these in-body headers that are used only during the
> transit over e-mail forwarding chain).
>
> But your patch seems to assume that the input message to send-email
> already has the in-body header.  Doesn't that indicate a misuse of
> the tool, making this new "feature" smell more like a way to
> encourage such a misuse by covering up the result?
>
> I dunno.

I forgot to mention that possible enhancements. As you mentioned,
there is only a minimal support for this in send-email.  After you
committed somebody else's patch in your tree, format-patch will
produce the normal From: and Date: using the original author's
identity and timestamp, but send-email only uses the in-body header
for "From:" (but not "Date:") to propagate this information and only
when the author is different from yourself.  It is plausible that
two new options to tell send-email to optionally

 (1) propagate "Date:" in the output from format-patch as an in-body
     header; and

 (2) propagate "From:" in the output from format-patch as an in-body
     header even when you are sending out your own patch

would support the recent kernel submission convention better.