From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#52507: [PATCH] Option for vc-delete-file to keep file on disk Date: Mon, 20 Dec 2021 02:46:29 +0300 Message-ID: References: <20211215095324.18195-1-ashwin@ashwink.com.np> <86a6h13j4i.fsf@mail.linkov.net> <85o85hsr3b.fsf@ashwink.com.np> <861r2dzqrj.fsf@mail.linkov.net> <85fsqt67y1.fsf@ashwink.com.np> <8535mt67k8.fsf@ashwink.com.np> <86k0g4a875.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33909"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Cc: 52507@debbugs.gnu.org To: Juri Linkov , Ashwin Kafle Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 20 00:48:10 2021 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 1mz5uU-0008dU-7N for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Dec 2021 00:48:10 +0100 Original-Received: from localhost ([::1]:35734 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mz5uS-0001AZ-DK for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 19 Dec 2021 18:48:08 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60104) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mz5uN-0001AQ-1A for bug-gnu-emacs@gnu.org; Sun, 19 Dec 2021 18:48:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36942) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mz5uL-0007Mq-Re for bug-gnu-emacs@gnu.org; Sun, 19 Dec 2021 18:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mz5uL-0002Vd-Nf for bug-gnu-emacs@gnu.org; Sun, 19 Dec 2021 18:48:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Dec 2021 23:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52507 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 52507-submit@debbugs.gnu.org id=B52507.16399576589514 (code B ref 52507); Sun, 19 Dec 2021 23:48:01 +0000 Original-Received: (at 52507) by debbugs.gnu.org; 19 Dec 2021 23:47:38 +0000 Original-Received: from localhost ([127.0.0.1]:48488 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mz5ty-0002TM-48 for submit@debbugs.gnu.org; Sun, 19 Dec 2021 18:47:38 -0500 Original-Received: from mail-wr1-f53.google.com ([209.85.221.53]:36598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mz5tw-0002Sm-Vv for 52507@debbugs.gnu.org; Sun, 19 Dec 2021 18:47:37 -0500 Original-Received: by mail-wr1-f53.google.com with SMTP id r17so16192392wrc.3 for <52507@debbugs.gnu.org>; Sun, 19 Dec 2021 15:47:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nfXZaN7edxXF22GxCqRVib/IkkPzzLW+zzZ4WvXCnLI=; b=KD1aEvzgyT+fC6mUbGbjTqMQwydlDmIaEhbgKBK5J9nmsAdZ/fCTd7byBk2mHQR9vG u0HsBOkYrStoA1X6O5fyvOXiFc3nBI4RKGHd2AcfjkBYZ+2Qw29koOsVOCeSk5hz1GMW VexwxPRkqwPEEayn3sDJVN0ZYryVAat4OGwijx16ppZ5Yw5OerwuKz9pZ5RwKibalUjN FV10aQQWu0YtRmOW1MxtdaXs/307z8GdkOs2eo+LvX6JjBSKAJI8mwlJ43hSIBLtISVt GBGTmKGwpyOCMxNkRAwSIW0UPz+fO8tC2BkEhLrLDaImoJ4y3N6h+I5NQTclm2XFQXlg 2yAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nfXZaN7edxXF22GxCqRVib/IkkPzzLW+zzZ4WvXCnLI=; b=dsnzAVSKitNtpz6VUCIWwDlIt57hwA5H6PjMIkNAESIxXTJV0dj/uHYoG7YluJ7ZuN elz5opGjjPn4smnNxSlmNypqlORuVAfxuCgO6hmqYytPtRJsPMu9ZJf2Ddri1F6S6s95 oZcVJ+DJhg8kjiBfqwBw2hKNAYKdmKRPDjX+q+nQLWFf3/nam5dWu5kxM0dfcpD39Nv2 JegBxCpVvdasKW1r+S87868+NT9rFQ1q9wydQ0Z1U+2BugAckSoXHCLeA9EOpwayKXR0 xNuYALIdk7xAIe9wUTZqtPl4QiIyEnohA4SHWPkj91LxOPc/NhI+daCBFD9TXAluVOy5 ZnpQ== X-Gm-Message-State: AOAM531xRPodafETztGX2s8lcDSS2KE4KDY2Uhm2QP2svYxwoTYGlm1l jGe2/YN5joTN/01z9PdCUNPTplL6lSI= X-Google-Smtp-Source: ABdhPJy3nNwzOx5Fkv1aesIbs4io52WAPxTyrubB9gNCB2sBuyNfgbvNEn08r985s/yrYggfAjhwBg== X-Received: by 2002:a05:6000:1867:: with SMTP id d7mr10948454wri.21.1639957651083; Sun, 19 Dec 2021 15:47:31 -0800 (PST) Original-Received: from [10.112.52.244] ([185.213.155.252]) by smtp.googlemail.com with ESMTPSA id i15sm21372182wmq.18.2021.12.19.15.47.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Dec 2021 15:47:30 -0800 (PST) In-Reply-To: <86k0g4a875.fsf@mail.linkov.net> Content-Language: en-US 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:222757 Archived-At: On 16.12.2021 20:01, Juri Linkov wrote: > --cached can't be used anyway, because vc commands doesn't use the git index. > Currently, after vc-delete-file, we have the following status in vc-dir: > > ./ > removed file1 > unregistered file1~ > > So the user can commit the removed file with vc-next-action. That's a very good point, I didn't even consider this problem (VC not caring about the staging area). Perhaps assuming that the full scenario with the original patch is functional. > Then after this, the user can manually rename the unregistered backup > by removing ~ from the file name. > > So it seems that you want to automate the last part, i.e. > to try automatically rename the file from its backup copy > after all changes were committed? So a "restore from backup" step indeed could be a solution for this problem. Or alternatively, if we consider the potential feature which we've been talking about (committing a subset of hunks from a file selectively), its implementation should have a step which either uses a staging area, or adds stuff to it first. And that step could be the place to enact a change like presently discussed (add a deletion to the staging area, and then commit it). That deletion would either already be in the staging area (meaning we pick up any staged changes for commit, which might be weird), or we would store the "intent to remove with --cached" in some buffer-local variable, which would be picked up by the new code. The latter solution would be the "cleaner" one, but the former is one that we could have _right now_. On the plus side, the former also doesn't seem like it's going to require changes in the VC API after all.