Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to

2 messages, 2 authors, 2016-06-16 · open the first message on its own page

Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to

From: Matthieu Moy <hidden>
Date: 2016-06-16 02:19:36

Junio C Hamano [off-list ref] writes:
Matthieu Moy [off-list ref] writes:
quoted
This should work, but sounds like too much of overloading of
--in-reply-to IMHO: if given a message id, it would only add a reference
to this message-id, but if given a file, it would also modify the To:
and Cc: list.

Not a strong objection, though.
Well, with your "that is the plan indeed", the option would behave
the same whether given a message ID or a filename, no?
The "fetch message from ID" feature should not be unconditional IMHO. So
it would probably be stg like:

  git send-email --in-reply-to=<id> --fetch

What's a bit counter-intuitive is that --fetch would not only trigger
fetching the complete message, but also populate To/Cc. But thinking
about it, it's not _that_ counter-intuitive, as fetching the message
should be done for a reason, so the user can guess that the message is
going to be used for something.

So, a possible UI would be:

  git send-email --in-reply-to=<id> => just set In-Reply-To: field.

  git send-email --in-reply-to=<file> => set In-Reply-To, To and Cc.

  git send-email --in-reply-to=<file> --cite => in addition, add the
    body of the message quoted with '> '.

  git send-email --in-reply-to=<id> --fetch => fetch and do like <file>
    using the default configuration for fetch.

This leaves room for:

  git send-email --in-reply-to=<id> --fetch=gmane => fetch from gmane
    (details on how to fetch would be in the config file)

This UI wouldn't allow using a file to get only the message-id. But I'm
not sure this is an interesting use-case.

So, I guess you convinced me.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to

From: Samuel GROOT <hidden>
Date: 2016-06-16 02:19:36

On 05/25/2016 08:31 PM, Matthieu Moy wrote:
So, a possible UI would be:

  git send-email --in-reply-to=<id> => just set In-Reply-To: field.

  git send-email --in-reply-to=<file> => set In-Reply-To, To and Cc.

  git send-email --in-reply-to=<file> --cite => in addition, add the
    body of the message quoted with '> '.

  git send-email --in-reply-to=<id> --fetch => fetch and do like <file>
    using the default configuration for fetch.
We designed a similar UI, except for the --fetch option:

We wanted to try to fetch the email from a distant server (e.g. gmane)
if that server address was set in the config file, and populate the
To:/Cc: fields.

If the file cannot be downloaded, or server address not set, just fill 
the Reply-to header.

Either way, display what was done with the message-id given (unless
--quiet is set, of course).
This leaves room for:

  git send-email --in-reply-to=<id> --fetch=gmane => fetch from gmane
    (details on how to fetch would be in the config file)

This UI wouldn't allow using a file to get only the message-id. But I'm
not sure this is an interesting use-case.
IMHO when you reply to a thread with a patch, it seems
counter-productive to reply without notifying (putting in To:/Cc:) the
original author and people involved in the thread.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help