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

[Juri Linkov <juri@linkov.net>]

> 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.

The feature of committing a subset of hunks will be performed by one command
'log-edit-done' ('C-c C-c') from the *vc-log* buffer that will run git commands
`git apply --cached` followed by `git commit`.

Doing something similar could mean for example that 'C-u M-x vc-delete-file'
could immediately pop up the *vc-log* buffer waiting for a commit message,
and on 'C-c C-c' will commit only the deleted file.

I doubt that anyone might want to commit the file deletion immediately,
because file deletions usually are committed together with other changes.

But maybe git has a way to mark a file as deleted without actually deleting it?
So `git status --porcelain -z --untracked-files` could return "D" for such file
that still exists, this would be the simplest solution.