From: Dmitry Gutov <dgutov@yandex.ru>
To: Juri Linkov <juri@linkov.net>, Ashwin Kafle <ashwin@ashwink.com.np>
Cc: 52507@debbugs.gnu.org
Subject: bug#52507: [PATCH] Option for vc-delete-file to keep file on disk
Date: Mon, 20 Dec 2021 02:46:29 +0300 [thread overview]
Message-ID: <f6dc58c6-3139-0dd4-f695-a6162fffe906@yandex.ru> (raw)
In-Reply-To: <86k0g4a875.fsf@mail.linkov.net>
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.
next prev parent reply other threads:[~2021-12-19 23:46 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-15 9:53 bug#52507: [PATCH] Option for vc-delete-file to keep file on disk Ashwin Kafle
2021-12-15 16:53 ` Juri Linkov
2021-12-15 17:41 ` Ashwin Kafle
2021-12-15 18:06 ` Juri Linkov
2021-12-15 18:26 ` Ashwin Kafle
2021-12-15 18:34 ` Ashwin Kafle
2021-12-16 17:01 ` Juri Linkov
2021-12-19 23:46 ` Dmitry Gutov [this message]
2021-12-23 17:20 ` Juri Linkov
2021-12-24 0:48 ` Dmitry Gutov
2021-12-26 17:43 ` Juri Linkov
2021-12-26 19:12 ` Dmitry Gutov
2021-12-26 14:31 ` Ashwin Kafle
2021-12-26 14:23 ` Ashwin Kafle
2021-12-26 15:38 ` Dmitry Gutov
2021-12-26 15:51 ` Ashwin Kafle
2021-12-26 15:57 ` Dmitry Gutov
2021-12-26 16:12 ` Ashwin Kafle
2021-12-26 16:28 ` Dmitry Gutov
2021-12-26 17:03 ` Ashwin Kafle
2021-12-27 0:03 ` Dmitry Gutov
2021-12-27 4:08 ` Ashwin Kafle
2021-12-28 0:53 ` Dmitry Gutov
2022-09-08 14:17 ` bug#52508: " Lars Ingebrigtsen
2021-12-26 17:41 ` bug#52507: " Juri Linkov
2021-12-27 17:58 ` Juri Linkov
2021-12-15 22:59 ` Dmitry Gutov
2021-12-16 7:12 ` Ashwin Kafle
2021-12-16 10:03 ` Dmitry Gutov
2021-12-16 11:26 ` Ashwin Kafle
2021-12-16 11:27 ` Dmitry Gutov
2021-12-16 14:07 ` bug#52507: [PATCH v3] " Ashwin Kafle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f6dc58c6-3139-0dd4-f695-a6162fffe906@yandex.ru \
--to=dgutov@yandex.ru \
--cc=52507@debbugs.gnu.org \
--cc=ashwin@ashwink.com.np \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).