Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > Actually, I'm not sure what the ideal behavior should be. Perhaps it's > better to distinguish 1) and 2) above, and have two options > --reply-to-email=<file> doing 1), and --quote doing 2), implying > --compose and requiring --reply-to-email. I tend to agree that sounds like a better way to structure these features. I wonder if we can safely repurpose existing --in-reply-to option? That is, if the value of --in-reply-to can be reliably determined as a filename that has the message (as opposed to a message-id), we read the "Message-Id:" from that file to figuire out what message-id to use, and figure out To/Cc: to use for the purpose of your (1) at the same time. In the future, you might even teach send-email, perhaps via a user configurable hook, a way to get to the message header and text given a message-id, and when it happens, the same logic can be used when --in-reply-to is given a message-id (i.e. you go from the id to the message and find the addresses you would To/Cc: your message). > In any case, quoting the message without replying to it does not make > sense (especially if you add instructions to trim it: the user would not > even see it). So it its current form, I'd say --quote-email should imply > --annotate. -- 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