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: ane@iki.fi,  57400@debbugs.gnu.org
>> Date: Fri, 26 Aug 2022 12:05:07 +0000
>> 
>> >> > 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.
>
> What do you mean by "MUA can recognize" here? which Emacs MUA
> recognizes Git-formatted patches and applies them?

The MUA recognizes the patch as a an attachment.  E.g. in Gnus the patch
is highlighted and "|" is bound to a command that pipes the contents of
the attachment through a command.

> What I do is invoke "M-|" and send the region to "git am".  That
> requires myself to recognize the patches, not the MUA I use.

I hadn't considered that, but again, if we are thinking about preparing
messages that are sent out to other developers using other MUAs, then I
don't know if this kind of functionality is available.

>> 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".
>
> Do you intend to provide a VC front-end to applying the patch-set, as
> part of this job?  Because if not, what happens on the receiving end
> is out of the scope of the feature we are discussing.

No, this is just about sending patches, but if the patches sent out are
of no use to the developers receiving them, then the feature is not as
useful as it could be.

>> > 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.
>
> We should have a user option that doesn't require project.el
> (project.el can override it, of course).  There should be no
> requirement to use project.el to send patches from VC.

There should be no need for project.el, this could just be set in dir
.dir-locals.el file in emacs.git.

But I don't think there is an actual issue here, the plan has been all
along to provide both kinds of patches (git am-style, attached) to be
sent out.