From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Antoine Kalmbach Newsgroups: gmane.emacs.bugs Subject: bug#57400: 29.0.50; Support sending patches from VC directly Date: Fri, 26 Aug 2022 16:10:58 +0300 Message-ID: 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> <83lerb197w.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22393"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 57400@debbugs.gnu.org To: Eli Zaretskii , Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 26 15:12:58 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 1oRZ8s-0005fD-9F for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 26 Aug 2022 15:12:58 +0200 Original-Received: from localhost ([::1]:54944 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oRZ8r-0005FA-13 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 26 Aug 2022 09:12:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55282) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oRZ80-0004zT-CO for bug-gnu-emacs@gnu.org; Fri, 26 Aug 2022 09:12:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34682) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oRZ7y-0002Rg-TT for bug-gnu-emacs@gnu.org; Fri, 26 Aug 2022 09:12:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oRZ7y-0002m6-E3 for bug-gnu-emacs@gnu.org; Fri, 26 Aug 2022 09:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Antoine Kalmbach Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Aug 2022 13:12: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.166151946810591 (code B ref 57400); Fri, 26 Aug 2022 13:12:02 +0000 Original-Received: (at 57400) by debbugs.gnu.org; 26 Aug 2022 13:11:08 +0000 Original-Received: from localhost ([127.0.0.1]:52664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oRZ75-0002kk-Qa for submit@debbugs.gnu.org; Fri, 26 Aug 2022 09:11:08 -0400 Original-Received: from meesny.iki.fi ([195.140.195.201]:35572) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oRZ70-0002kH-35 for 57400@debbugs.gnu.org; Fri, 26 Aug 2022 09:11:06 -0400 Original-Received: from qfinm256.local (unknown [66.159.213.92]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: ane) by meesny.iki.fi (Postfix) with ESMTPSA id 4E8BE200BF; Fri, 26 Aug 2022 16:10:59 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1661519460; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OblYlGQm2sjzpdxUde/M1vQxHVUlqdFYPi5Xq0Kx5e4=; b=hY0UcjH0UBCh32mpQmJCZ4GFaaMEzjVwu5Z5/Q0zBfqBz+UhWzp6vLf6B2/FzK4ACJ296d EupWg8S13WyNJJKnp6WGA+3AtNvk1iHIJZ94xE8QUGk9H3x60GOF/ESqzB7EKbyPnADftR AHaqDhjHe0ffhL8063pvsQZFR7Gap1w= In-Reply-To: <83lerb197w.fsf@gnu.org> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1661519460; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OblYlGQm2sjzpdxUde/M1vQxHVUlqdFYPi5Xq0Kx5e4=; b=jTcdTRay/HRCeJHLGc2lXpNAp/xRwp3odkyQXRnGcliEIs1IbsGjLIFrZ+jv0hn79LKCUM L4VGYX10O7fX2pSDgWz5xAPYbiRLV8sifuCccMYv2tALh4lzHtwqJzbL8x5uroonGXZ9CB h7zbw1dhs8siG127PbbiqLfOgEAmJ0U= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=ane smtp.mailfrom=ane@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1661519460; a=rsa-sha256; cv=none; b=yeiWVAlWMkkDpsTK5IHpmqbyFx6VNqb5modI4nJMtF7ksjOVSRoBx849XSnNSCbvQXM1+L hK/lEtAVEtJyZJBbAHzhXqMrPunioQpVxa2+Yl4CkpgcSkHQ6Ch8zgBVaFvqOhhDoH45pz 2NFjzIL3SQvBZEWiGFnDOTTKsBg+5FI= 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:240836 Archived-At: Eli Zaretskii writes: >> 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? I don't think any does. Insofar as Mutt and Aerc are concerned, all they provide is functionality for syntax highlighting the diff and then a command for piping the message. Emacs can do, and does, both of those. (At least Gnus highlights patch blocks.) > 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? The standard Git approach is to just pipe the whole message, expecting the patch to be in the email directly. Or even with attachments, can you actually mark the whole email buffer and pipe that? > 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. > > 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. -- Antoine Kalmbach