Junio C Hamano <gitster@xxxxxxxxx> writes:
> Stepan Kasal <kasal@xxxxxx> 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.
--
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