bug#52507: [PATCH] Option for vc-delete-file to keep file on disk

[Dmitry Gutov]

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.