Jeff King <p...@peff.net> writes:

>> @@ -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.
--
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

Reply via email to