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

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Antoine Kalmbach <ane@iki.fi>,  57400@debbugs.gnu.org
>> Date: Fri, 26 Aug 2022 11:26:29 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >>   5. Loop each file in `message-mode`. `C-c C-c` sends and goes to the
>> >>      next patch, `C-c C-k` cancels the whole thing.
>> >
>> > Please don't hard-code message-mode.  Please honor the user setting of
>> > mail-user-agent instead.
>> 
>> Is there a generic way to handle any mail-user-agent?
>
> For some value of "generic way to handle", yes.  For example,
> compose-mail does that.
>
>> E.g. if you want to add attachments, is there any better way that
>> just doing a case distinction on known user agent implementations?
>
> Not sure about attachments, but we could either add another property
> to mail-user-agent, like we do with composefunc property, or dispatch
> on the agent itself.

That sounds like a good approach.

>> > Also, I'm not sure why we'd need to send each patch file separately.
>> > Why not add them one by one as attachments to the same email message?
>> 
>> This wouldn't work if we are sending patches to a mailing list that
>> assumes patches are sent out by git send-email, and that the messages
>> can be filtered through git am.
>
> "git am" handles attachments without any problems, I do it all the
> time.

Only if the MUA can recognise the patch and pipe it into a git am
process.  But if we are trying to re-create the behaviour of "git
send-email" (as I think is necessary if we want the feature to be of use
outside of Emacs circles, such as sending a patch to the Linux Kernel
Mailing List), then we need to consider people using clients like Mutt
or Aerc (https://aerc-mail.org/) that just pipe the entire message
through "git am".

> But I don't object to having optional behaviors here.  My point is
> that we should allow sending all the patches together, as that is the
> preferred/usual practice in Emacs development.

Of course, the idea that was proposed on emacs-devel was to have this
behaviour be controlled by a (file-local) variable that could be set on
a per-project basis.