bug#57400: 29.0.50; Support sending patches from VC directly

[Philip Kaludercic]

Juri Linkov <juri@linkov.net> writes:

>>> Also please note that the most convenient way to select revisions
>>> to submit is to show the log buffer, and use 'm' to mark revisions
>>> (log-view-toggle-mark-entry).  Then 'log-view-get-marked' returns
>>> all marked revisions.
>>
>> This is supported,
>
> Thanks.  Since it's the most convenient UI, shouldn't this be
> documented in the Info?  IOW, what about copying this from the docstring
> to the manual:
>
>   When invoked interactively in a Log View buffer with marked
>   revisions, these revisions will be used.

I can add that.

> Also the use of "," to separate revisions needs to be documented
> in the docstrings and the manual.  Maybe also mention the separator
> in the prompt that reads multiple revisions.

Actually it is whatever was specified by `crm-separator', right?  But
yes, that can be mentioned too.

>> but currently not in this order.  Do you think an option should be
>> added that would use recursive editing to prompt the user?
>
> I see that currently the chronological order of revisions is used from
> the log.  This looks like the right order.  Prompting with the default
> value that is set to these revisions from the log would be also nice
> to do, so users will be able to change the order manually by moving
> revisions between ",".

Again, regarding `crm-separator' I don't know if this is a value that
people change or not (perhaps it should be changed to a defconst).  But
setting that aside, that sounds like a good idea.

I can also imagine that the initial input outside of a log buffer ought
to just be the last commit.

> Additional question: shouldn't the behavior of
> vc-prepare-patches-separately=nil be equivalent to
> vc-prepare-patches-separately=t when only one revision is given?  Both
> cases create just one mail.  So when vc-prepare-patches-separately is
> nil, could it extract the subject from the single revision?  Or maybe
> vc-prepare-patches-separately should support a new customization value
> for this?

Yes, but the formatting is different.  In the one case you attach a
patch to a regular message, while in the other case the message is
prepared in such a way that (at least when using Git) the entire message
is a valid patch, where we can use "git am".