Junio C Hamano <gits...@pobox.com> writes: > Stepan Kasal <ka...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html