[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.
- bug#57400: 29.0.50; Support sending patches from VC directly, Antoine Kalmbach, 2022/08/25
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/08/26
- bug#57400: 29.0.50; Support sending patches from VC directly, Antoine Kalmbach, 2022/08/26
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/08/26
- bug#57400: 29.0.50; Support sending patches from VC directly, Antoine Kalmbach, 2022/08/26
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/08/26
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/08/26
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/08/26
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/08/26
- bug#57400: 29.0.50; Support sending patches from VC directly,
Eli Zaretskii <=
- bug#57400: 29.0.50; Support sending patches from VC directly, Antoine Kalmbach, 2022/08/26
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/08/26
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/08/26
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/08/26
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/08/27
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/08/27
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/08/27
- bug#57400: 29.0.50; Support sending patches from VC directly, Antoine Kalmbach, 2022/08/26
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/08/26
- bug#57400: 29.0.50; Support sending patches from VC directly, Richard Stallman, 2022/08/28