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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

>> ... <helper function to see if the user is the author> ...
>> +}
>
> Nice, I'm glad you handled this case properly. I've wondered if we
> should have an option to do a similar test when writing out the "real"
> message format. I.e., to put the extra "From" line in the body of the
> message when !is_current_user(). Traditionally we have just said "that
> is the responsibility of the MUA you use", and let send-email handle it.
> But it means people who do not use send-email have to reimplement the
> feature themselves.

I am not sure if I follow.  Do you mean that you have to remove
fewer lines if you omit Date/From when it is from you in the first
place?  People who do not use send-email (like me) slurp the output
0001-have-gostak-distim-doshes.patch into their MUA editor, tell the
MUA to use the contents on the Subject: line as the subject, and
remove what is redundant, including the Subject.  Because the output
cannot be used as-is anyway, I do not think it is such a big deal.

And those who have a custom mechanism to stuff our output in their
MUA's outbox, similar to what imap-send does, would already have to
have a trivial parser to read the first part of our output up to the
first blank line (i.e. parsing out the header part) and formatting
the information it finds into a form that is understood by their
MUA.  Omitting From: or Date: lines would not help those people who
already have established the procedure to handle the "Oh, this one
is from me" case, or to send the output always with the Sender: and
keeping the From: intact.  So,...

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]