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.devel Subject: Re: master 4803fba487 1/2: 'C-x v v' on a diff buffer commits it as a patch (bug#52349) Date: Tue, 30 Aug 2022 14:25:20 +0300 Message-ID: <83tu5uug68.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11729"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, juri@jurta.org, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 30 13:26:47 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 1oSzOJ-0002uV-EC for ged-emacs-devel@m.gmane-mx.org; Tue, 30 Aug 2022 13:26:47 +0200 Original-Received: from localhost ([::1]:57246 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oSzOI-0006W0-7B for ged-emacs-devel@m.gmane-mx.org; Tue, 30 Aug 2022 07:26:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59396) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oSzMY-0005gs-AZ for emacs-devel@gnu.org; Tue, 30 Aug 2022 07:24:58 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43872) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oSzMX-0006Hs-Pf; Tue, 30 Aug 2022 07:24:57 -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=ky23a8/57ZbYiEWjbhpJlE1I+oxCakDm7jb0Nl6uMGY=; b=i+s/n+OTt5tD 9pEMJ59bWeMpR6NPiPI36a/fXPd/frmKVSST+iT+VSSRS6W78nvXK4WEO8DxQyWsZHiOYPrONu72p xtXO5uhL1/Z65B0/qmVXhVkV07tw67RixgQA4KDIVtPhNnuPprIGpsI1FLTLQ7MGXJh94O5DLAqlq Q2mi46fkqrNCnVjUn5RmbjsVIokNWA2J1L9aO4owMrYI6hID657KHrWBEnAPeJGk8wf7JUyaiJogX bDZNeQn8pV2V4y7PRnl7WdVZLkl5sIygMHelViN9PnwPSo9udrxEFm4bTM8aEhZYJK7xToHN7x6xd +XVEonFtnxSezNraODv3yg==; Original-Received: from [87.69.77.57] (port=1940 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 1oSzMX-0001bT-6X; Tue, 30 Aug 2022 07:24:57 -0400 In-Reply-To: (message from Dmitry Gutov on Mon, 29 Aug 2022 23:36:32 +0300) 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:294329 Archived-At: > Date: Mon, 29 Aug 2022 23:36:32 +0300 > Cc: larsi@gnus.org, juri@jurta.org, emacs-devel@gnu.org > From: Dmitry Gutov > > > The implementation in vc-git.el does this, AFAICT: > > > > . creates a temporary file > > . inserts the patch into the temporary file > > Note that "the patch" will usually be a subset of the current 'git diff' > output. But not always (the patch can be additionally modified by hand). I understand. But how is this significant? Doesn't "git apply" require a valid patch as well? > This feature is a replacement for the popular workflow 'git add -p; git > commit', not for simply committing a patch, which is pretty easy to do > already. Yes, I understand that. > > . 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. (And using shell-command-on-region avoids the need to > > explicitly create a temporary file.) > > 'patch < file' edits the working directory. 'git apply --cached' edits > the index, keeping the files themselves unchanged. I'm not sure why is this significant. Doesn't committing the patch from the index eventually update the files on disk as well? And if not, how is this feature useful? you get a repository where the contents of the .git/ directory doesn't match the worktree, right? When is this needed or 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? > > Index is a solution, not the problem. The problem is other changes being > present on disk. For other changes present on disk, we cam: . use the equivalent of the "stash" command, where the VCS supports it . otherwise, commit specific files by name, where the VCS supports that . otherwise signal an error, asking the user to clean up the tree > I suppose we could implement a scaled-down version of this feature as a > fallback (the one that ensures that there are no existing changes in > affected files), but I fear the difference between the backends would > trip up the users. AFAICT, Mercurial, Bazaar, RCS, CVS, and SVN all support committing an explicit list of files, so dirty working tree shouldn't be a problem for them. The first two also have a "stash"-like functionality. But even if we initially only support this in otherwise clean trees, it will be a huge advantage vs the current situation, where this feature is simply not available.