From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#57400: 29.0.50; Support sending patches from VC directly Date: Fri, 26 Aug 2022 15:26:59 +0300 Message-ID: <83lerb197w.fsf@gnu.org> References: <84v8qgn1z9.fsf@iki.fi> <87h71zo3p8.fsf@posteo.net> <87sfljmgwz.fsf@posteo.net> <83sflj1dbo.fsf@gnu.org> <87fshjmeje.fsf@posteo.net> <83mtbr1b6l.fsf@gnu.org> <87tu5zky6k.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39333"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 57400@debbugs.gnu.org, ane@iki.fi To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 26 14:29:59 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oRYTH-000A0x-Gi for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 26 Aug 2022 14:29:59 +0200 Original-Received: from localhost ([::1]:35310 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oRYTF-00048O-T2 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 26 Aug 2022 08:29:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36662) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oRYRO-0001wF-MS for bug-gnu-emacs@gnu.org; Fri, 26 Aug 2022 08:28:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34596) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oRYRO-0001pb-Bk for bug-gnu-emacs@gnu.org; Fri, 26 Aug 2022 08:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oRYRO-0003Rg-3d for bug-gnu-emacs@gnu.org; Fri, 26 Aug 2022 08:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Aug 2022 12:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57400 X-GNU-PR-Package: emacs Original-Received: via spool by 57400-submit@debbugs.gnu.org id=B57400.166151682513171 (code B ref 57400); Fri, 26 Aug 2022 12:28:02 +0000 Original-Received: (at 57400) by debbugs.gnu.org; 26 Aug 2022 12:27:05 +0000 Original-Received: from localhost ([127.0.0.1]:52578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oRYQS-0003QN-Rp for submit@debbugs.gnu.org; Fri, 26 Aug 2022 08:27:05 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52826) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oRYQJ-0003Ph-7U for 57400@debbugs.gnu.org; Fri, 26 Aug 2022 08:27:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48598) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oRYQC-0001Su-2J; Fri, 26 Aug 2022 08:26:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=j75ebuoETUl5EB6MMwv1Ny3z9GHtem4fflJ+w5LTwag=; b=CXAJ2wUOD2LS x6MKWN9IEjJplh4NdXNLTU8mHOfv0rRyth7cYL0W3ylrpDF7urqQtHFbyUkfpxjWVrZRh0sAJIoBj CJKG0Anf/MnU1tbcAB9/iV1fWeaA864v0I7GwjvrQyHf1rpdR4hihgk5yhwAB9j+CbPE8DBoGpp+E aBS9Iq3Ri9W8eK8s6EJeKNPd1ZyziOwnXMmsrydb6KvT/RBFY+vboffKVTEdu/kCgxCHZ/ci0AID1 jUM0LvlLX2dFuVU0AxMJ8OowU6NYJXSfpO15Inn1F2D+P6tptohOjlpJC6X2oWSmuujEL05dWhN4W /zKMjnNJc0N4CznpFmy4xQ==; Original-Received: from [87.69.77.57] (port=4450 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oRYQA-0008Dg-NI; Fri, 26 Aug 2022 08:26:47 -0400 In-Reply-To: <87tu5zky6k.fsf@posteo.net> (message from Philip Kaludercic on Fri, 26 Aug 2022 12:05:07 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:240824 Archived-At: > From: Philip Kaludercic > 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.