From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: master 4803fba487 1/2: 'C-x v v' on a diff buffer commits it as a patch (bug#52349) Date: Mon, 29 Aug 2022 21:03:50 +0200 Message-ID: <8735dec0uo.fsf@gnu.org> References: <166171593185.16640.41619657947456727@vcs2.savannah.gnu.org> <20220828194533.23A6BC00889@vcs2.savannah.gnu.org> <87r10znm0y.fsf@gnus.org> <83fshfvvyn.fsf@gnu.org> <83bks3vtf5.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="3414"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.9.0; emacs 29.0.50 Cc: Dmitry Gutov , larsi@gnus.org, juri@jurta.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 29 21:22:09 2022 Return-path: Envelope-to: ged-emacs-devel@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 1oSkKl-0000ey-KC for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Aug 2022 21:22:07 +0200 Original-Received: from localhost ([::1]:47422 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oSkKi-0003uF-At for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Aug 2022 15:22:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35764) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oSkK4-0003EL-Ay for emacs-devel@gnu.org; Mon, 29 Aug 2022 15:21:24 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58550) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oSkK3-0006AV-By; Mon, 29 Aug 2022 15:21:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-reply-to:Date:Subject:To:From: References; bh=xcD2oA4IsdU6U7ZZEhyjJJyVVmVM9KyFHcYEn4G4tpU=; b=UHeslAvLTzphZD GITY9rz4SbUKSc/Kfh9/XnrM2jwm6LAul0JJvUBOn9lm5VA9Q8TaGwZ+HbxUQjNB89d9p4XOmOkXJ OMAJ1URS7KN51Ke3r+2MwIARfPP8CLssJ6G0pMDRX2eZU1NREC8zcfkEb756kyNtbN6nEsXjI3+bF nlv2HOG7fuVJAfhqEWo165yYhoAx52tR7L35lFdl3wb6v/sIgUhJlR/+IWq2hDIreGRNVJs4PuvSD 2I8gSqMK53efVCA7hrxEtT/xa/Tkf2iNpAbXMJQarG84VNWkuQ6C3cmd2CyoHfLEDfI4ES1VKC74C Bgcv/eFmJ5TYOxQPWlMA==; Original-Received: from auth2-smtp.messagingengine.com ([66.111.4.228]:58093) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oSkK3-0001HE-3T; Mon, 29 Aug 2022 15:21:23 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id BE57027C0054; Mon, 29 Aug 2022 15:21:22 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 29 Aug 2022 15:21:22 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdekuddgudefjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpehffgfhvfevufffjgfkgggtsehttdertddtredtnecuhfhrohhmpefvrghs shhilhhoucfjohhrnhcuoehtshguhhesghhnuhdrohhrgheqnecuggftrfgrthhtvghrnh epudejtdehuddvleffjeekteegvdehleehvdeufefhueekkeekhedvgfeggeffvefgnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhrnh domhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqkeeijeefkeejkeegqdeifeeh vdelkedqthhsughhpeepghhnuhdrohhrghesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Feedback-ID: ib2b94485:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 29 Aug 2022 15:21:21 -0400 (EDT) In-reply-to: <83bks3vtf5.fsf@gnu.org> X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:294300 Archived-At: Eli Zaretskii writes: >> No, 'git apply' puts the patch in a different place (index area), >> which means our implementation doesn't need to bother with moving all >> existing changes in the selected files somewhere else, then >> committing, and then restoring the previously-hidden changes. > > I don't follow, sorry. > > The implementation in vc-git.el does this, AFAICT: > > . creates a temporary file > . inserts the patch into the temporary file > . calls "git apply --cached" on the patch in the temporary file > . deletes the temporary file > > This doesn't seem to be very different from invoking Patch on the > diffs. I think the difference is that "git apply --cached foo.patch" exits non-zero if the index isn't empty and vc-git-checkin errors when it's not. That ensures the commit will include only the changes in the patch and nothing else. I guess other VCS impls could just test if the checkout is completely unmodified and signal an error otherwise. That would be a bit more restrictive but still useful. >> Personally I hope we discover some popular extension to Mercurial >> which we'll be able to use in the same way as we do Git's index area >> here. And then say job well done and keep the less-popular and >> outdated backends unsupported. > > The index thing being the problem because Git needs to have the > changes in the index before you can commit? Or is there any other > reason? I think the git benefit is that you can have a completely dirty checkout (hundreds of modified files) but the command will still work fine as long as you haven't staged other changes yet. > IOW, why cannot we simply patch the files, and then run the equivalent > of vc-checkin? See above, I think we can at least after a "is the checkout clean?" check. Bye, Tassilo