Adam Spiers [off-list ref] writes:
OK, thanks for the information. IMHO it would be nice if 'git
format-patch' and 'git am' supported this style of inline patch
inclusion, but maybe there are good reasons to discourage it?
"git am --scissors" is a way to process such e-mail where the patch
submitter continues discussion in the top part of a message,
concludes the message with:
A patch to do so is attached.
-- >8 --
and then tells the MUA to read in an output from format-patch into
the e-mail buffer. You still need to strip out unneeded headers
like the "From ", "From: " and "Date: " lines when you add the
scissors anyway, and this is applicable only for a single-patch
series, so the "feature" does not fit well as a format-patch option.
On Tue, Feb 19, 2013 at 06:53:07PM -0800, Junio C Hamano wrote:
Adam Spiers [off-list ref] writes:
quoted
OK, thanks for the information. IMHO it would be nice if 'git
format-patch' and 'git am' supported this style of inline patch
inclusion, but maybe there are good reasons to discourage it?
"git am --scissors" is a way to process such e-mail where the patch
submitter continues discussion in the top part of a message,
concludes the message with:
A patch to do so is attached.
-- >8 --
and then tells the MUA to read in an output from format-patch into
the e-mail buffer.
Ah, nice! I didn't know about that.
You still need to strip out unneeded headers
like the "From ", "From: " and "Date: " lines when you add the
scissors anyway, and this is applicable only for a single-patch
series, so the "feature" does not fit well as a format-patch option.
Rather than requiring the user to manually strip out unneeded headers,
wouldn't it be friendlier and less error-prone to add a new --inline
option to format-patch which omitted them in the first place? It
should be easy to make it bail with an error when multiple revisions
are requested.