GNU bug report logs - #57400
29.0.50; Support sending patches from VC directly

Previous Next

Full log

Message #35 received at 57400 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 57400 <at> debbugs.gnu.org, ane <at> iki.fi
Subject: Re: bug#57400: 29.0.50; Support sending patches from VC directly
Date: Fri, 26 Aug 2022 15:26:59 +0300

> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: ane <at> iki.fi,  57400 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.