Re: [PATCH 2/2] format-patch: --inline-single

Jeff King [off-list ref] writes:

quoted

@@ -421,6 +443,9 @@ void pp_user_info(const struct pretty_print_context *pp,
 	if (pp->mailmap)
 		map_user(pp->mailmap, &mailbuf, &maillen, &namebuf, &namelen);
 
+	if (pp->inline_single && is_current_user(pp, mailbuf, maillen, namebuf, namelen))
+		return;
+
 	strbuf_init(&mail, 0);
 	strbuf_init(&name, 0);

This makes sense to suppress the user line when it is not necessary. But
we should probably always be suppressing the Date line, as it is almost
always useless.

When I (figuratively) am sending my patch in a discussion, saying
"You could do it this way", on the other hand, I agree that the date
is uninteresting.

I however think I would prefer to keep the Date: line when I am
relaying somebody else's work during a discussion.  It is more like
"Yeah, Peff already did that with this commit; here it is for
reference". The fact that I have _your_ patch makes it more "done",
than the case I send out my own patch.

Besides, removing an extra line in the MUA editor is far easier than
having to type what the tool "helpfully" omitted, guided by an "it
is almost always useless" that is not backed by the user preference.
I'd rather err on the side of giving extra than omitting too much.

I also wonder if we should suppress the subject-prefix in such a case,
as it is not adding anything (it is not the subject of the email, so it
does not need to grab attention there, and it will not make it into the
final commit).

If the user does not want to waste too much space in the message,
not passing the --subject-prefix=foo from the command line, or
editing it out in the editor buffer if for some reason the user ran
the command with the option, are both easy things to do.  I do not
think extra lines to excise subject prefix is not worth it, and who
knows what the user's preferences are.

But there is something more important.

We should make sure that we disable MIMEy stuff (i.e. MIME-Version,
C-T-E: 8bit/quoted-printable, Content-type, etc.) when producing the
output to be appended to the body, which should be just a straight
8-bit text.  I do not think the posted patch tries to do anything to
that effect.