[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 16:17:07 +0300 |
> From: Antoine Kalmbach <ane@iki.fi>
> Cc: 57400@debbugs.gnu.org
> Date: Fri, 26 Aug 2022 16:10:58 +0300
>
> > 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.
>
> If the patch is attached, you open the patch, mark it, and then M-| git
> am, right?
Yes (modulo "cd .." to the right directory).
> The standard Git approach is to just pipe the whole message,
> expecting the patch to be in the email directly.
The patch attachments can all be shown inline, since they are text,
and then you can pipe the entire message, yes.
> Or even with attachments, can you actually mark the whole email buffer
> and pipe that?
I think I once did that, and it worked. Not sure.
But if you intend to provide/improve what happens on the receiving end
as well, then Emacs could filter the irrelevant parts from what it
sends down the "git am" pipe.
> > 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.
>
> Having a complementary `vc-apply-patch` wouldn't be a bad idea, but
> I think we should do the sending part first.
Fine by me.
> > 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.
>
> I think Philip means directory-local variables, not project.el.
Once we have an option, it can be included in directory-local
variables, right?
- bug#57400: 29.0.50; Support sending patches from VC directly, (continued)
- 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, 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 <=
- 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