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

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: ane@iki.fi,  57400@debbugs.gnu.org
> Date: Fri, 26 Aug 2022 13:29:22 +0000
> 
> >> 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.

I fail to see how other MUAs used by other developers are relevant
here.  We are talking about sending patches, not receiving them.
Sending them as attachments is a known, and frequently required or
preferred, technique.  How the patches are handled on the receiving
end is a separate problem, but it already has its solution, because
people send patches as attachments all over the place.

> >> 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.

They cannot be "of no use", because these practices are already in
use, regardless of whether Emacs does or doesn't support them.