bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#57400: 29.0.50; Support sending patches from VC directly
Date: Fri, 26 Aug 2022 15:26:59 +0300

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

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.

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

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]